#File protocols
4 messages in this thread
The ONLY thing Kermit has going for it is the fact that it is implemented on a
large number of machines. Personally I prefer spending 10 minutes downloading
and 1 minute CHOPing to spending 20 minutes downloading.
THE best protocol may not have been implemented yet, as all I have seen have a
few snags to catch you. One thing is certain though, any protocol that doesn't
approach the maximum theoretical transfer rate to within a few percent is NOT a
contender for being called evn good, let alone best.
Regards, Larry.
* Replies:
8711, 8723
Here's a suggestion for a better file transfer protecol. It came to mind after
reading all the messages concerning CHOP confusion. Why not have a protecol
that automatically squeezes a file, sends it through the phone lines, then
unsqueezes it at the receiving end. Better still, send a header that contains
the file name and other info that allows the receiver to specify whether the
file is to be unsqueezed. This would allow the squeezed version to remain on
CIS for example, then when a person downloaded the file the protecol would
detect that the file was already squeezed and would not attempt to squeeze it
again.
In the error detection area, I also have a suggestion. In my days working on
SCADA (Supervisory Control and Data Acquisition) systems we used a modified CRC
that was 6 bits long for a 4 byte transmission. This CRC was flipped (ie bit
0=bit 5, 1=4, etc) so that the error detection bits were still the last 6 in
the message, but were a mirror image. Apparently (I am no math whiz) this
decreased the odds of an error significantly over a regular CRC.
– Chris
* Reply:
8712
I know that there are Kermits available for both Prime and Univacs. As for line
delays, compression, and better window checking, I should have stated
originally that TheSource uses a new superset of the Kermit protocol called
"sliding windows", which involves sending a large number of packets (as many as
31) before waiting for an ACK. Since the ACK in Kermit is also a
sequence-numbered packet, the sender may receive an ACK with sequence number
25, which is an implicit ACK of packets 1-24 as well; the next bundle of
packets will include a retransmit of numbers 26 through 31, plus enough new
packets to make up the next group. The new protocol also includes compression
of data by the sender and uncompression by the server. Tests show 30 to 45%
reductions in transmission time over either XMODEM (128 byte packets) or old
Kermit (90 byte packets). –Steve
If AmigaBinary/Xmodem CRC has a count in the header …. you won't even have to
chop … and it will be compatable with compuserve.