Subj : binkley multinode, was something new
To   : Sean Dennis
From : mark lewis
Date : Thu Oct 15 2009 07:18 pm


 ml> i do EMSI with zmodem transfers over here all the time... the problem
 ml> with using the older FTN transfer protocols over telnet is the
 ml> timing... the older protocols (xmodem, ymodem, zmodem and all their

 SD> It's also the protocol driver.

right... the protocol driver (the actual protocol executable) is where the 
coder would have to tighten or loosen the timing windows so the protocols would 
work over slower connection tunnels...

 SD> I use P for OS/2, a real 32-bit driver that's better than anything 
 SD> else I've ever used, save for PD-ZModem for DOS. Absolutely 
 SD> painless to use and really fast to boot; it was written by someone 
 SD> who knew OS/2 really well. PD-ZModem was written by someone who 
 SD> knew how to optimize their DOS stuff to the T.  Used PDZ with 
 SD> ProBoard under DOS (OS/2-DOS) and it was amazingly fast, almost as 
 SD> fast as P!

 SD> But I digress. :)

i know the feeling... when joho had to rewrite FD and did it with an eye 
specifically aimed at using the internet for the connection, he had to tweak 
several of the protocols for looser timing windows to allow those ACKs and such 
plenty of time to return thru the congested pipeline... since he had the 3rd 
party sources for the protocols (more expensive library licensing) he was 
using, this was a pretty trivial matter... the real problem comes with software 
that uses 3rd party libraries that are only available in compiled unit or obj 
format (free or low cost licensing)... without the sources or some way to 
adjust the timings via parameters in the routine's call vectors, these are 
frought with peril... a very congested pipeline and even tcp/ip packets 
arriving out of order can easily cause a protocol to stop and backup or even 
miss ACKs and NAKs...

)\/(ark

 
* Origin:  (1:3634/12)

.