Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!umich!ox.com!tbomb!time Newsgroups: comp.sys.mac.comm Subject: Re: FTP Sun<-->Macintosh using SLIP (TCP/CONNECT II) Message-ID: <1CE00001.65w4j6@tbomb.ice.com> Date: 14 Feb 91 13:50:11 GMT Reply-To: time@ice.com Organization: ICE Engineering, Inc. Lines: 81 X-Mailer: uAccess - Mac Release: 1.0.5+ In article <5950@unix386.Convergent.COM>, markb@unix386.Convergent.COM (Mark Beyer) writes: > What is the technical reason that XMODEM and ZTerm are faster ? I'm > not familiar with those protocols. It is a matter of protocol. XMODEM ------ With XMODEM, you send 128 bytes packets over a serial connections with, I believe (can not remember exactly), 5 bytes of header which contains a checksum and packet ID. This checksum allows the receiving end to determine if the received packet is correct or needs to be resent. OVERHEAD: the header bytes, the time required to compute the checksum on both ends, the time delay waiting for an ACK to the last packet so you can send the next, and the delays inherent in resending any improperly received packets. ZMODEM ------ I am *very* weak on the protocol. With ZMODEM you send a continuous data stream with some type of checksum builtin. The receiving end simply receives and does not bother to ACK packets received correctly. When a bad packet comes in the receiving end "interrupts" the sender (with a BREAK I think) and causes the other end to go back to the failed packet and start from there. OVERHEAD: the checksum bytes and any go-backs caused by bad data. As you can see, if your connection is guarenteed (i.e., MNP or LAP-M) then you will get extraordinary throughput since the sender just "blasts" the data. SLIP/IP/UDP/TCP/FTP ------------------- First off, you must realize that TCP runs ontop of UDP on top of IP. (I believe this layering is not *mandatory* but is common place). Anyways, TCP uses UDP "packets" which are not guarenteed to arrive correctly (or at all). TCP guarentees a perfect byte stream by resending any UDP packets that didn't work. UDP packets are built ontop of IP which simply breaks up the wire into packets with addresses on them (remember, you are on a BIG wire, with many listeners). The overhead in UDP/IP packets is (20 + 8) 28 bytes (much more than in XMODEM). The TCP packets, however, add some 20 bytes more to this. Thus, your total header overhead is 48 bytes compared to 5 or 6!!!! So, TCP uses these UDP packets and has to resend as necessary (with *lots* of sophisticated algorithms for "backoff" and other things required when connections can take ten minutes to "send data") and creates this byte stream. OK, *now* add the added overhead of placing these low level UDP/IP packets into a serial line with SLIP. I am not sure of the overhead for SLIP, but I suspect you are talking serveral bytes per packet. And, of course, if your phone line is not that good, you get lots of overhead in re-sending packets that were corrupted. Depending on the software you are using, this nay be unexceptable if the packet size are too large (resending 4K packets several times is not good). If the packet size is made too small, then you get way too much overhead on the header bytes (128 bytes of data with 48+ bytes of header is also not good). Of course, V32 MNP modems help here. Alright, now you are ready for the actual file transfer! FTP will send some bytes concerning what is being sent and start blasting data! I do not believe FTP adds any overhead in the data stream. OVERHEAD: Looks like 48+ bytes per packet with resends. When you start adding the overhead bytes, things get inefficent. Compared to ZMODEM blasting a data stream anything else will seem slow. BUT ZMODEM will not connect you with sumex-aim archives either! Again, pick the best tool for your job. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208