protocom@terre (protocom-Laurent turcotte) (02/10/91)
I'm considering using (SLIP) via FTP to transfer files from a Macintosh to Sun Sparc station. I know 4.3BSD unix implements SLIP. I would be using TCP/Connect II 1.0 from Intercon Systems Corporation on the Macintosh side. The Sun would call the Macintosh via modem (SLIP) and establish an FTP session. (1) is SLIP reliable enough over noisy modem lines? (I know that the TCP and IP layers contains checksum block validations) or should I use something like ZMODEM or KERMIT. (2) is the question of speed which would be faster (SLIP/FTP, XMODEM or KERMIT) (3) which is the most flexible? I think SLIP since you can almost do anything with IP but send me your opinions. Thanks (any feedback can help...) Larry Turcotte -- Larry Turcotte Internet:protocom@dmi.usherb.ca computer science student/consultant consulting company:Protocom Is there anybody out there.....
kdb@macaw.intercon.com (Kurt Baumann) (02/13/91)
In article <1991Feb9.195637.26171@DMI.USherb.CA>, protocom@terre (protocom-Laurent turcotte) writes: > The Sun would call the Macintosh via modem (SLIP) and establish an FTP session. > Actually I think you mean that the Mac would call the SUN. At least that is how it would work with TCP/Connect II. Currently, when PPP is added things might change a bit. > (1) is SLIP reliable enough over noisy modem lines? (I know that the TCP and IP layers contains checksum block validations) or should I use something > like ZMODEM or KERMIT. > Sure, we have people who work here using it from home. I read mail and news from home using SLIP into our office. > (2) is the question of speed which would be faster (SLIP/FTP, XMODEM or KERMIT) > The benifits far out weight any problems with speed. It really depends on the type of modem you are using, and other factors, but speed is usually very good with SLIP, I don't complain and believe me I complain a lot when I have to wait. :-) > (3) which is the most flexible? I think SLIP since you can almost do anything with IP but send me your opinions. SLIP is definatly the most flexable. Imagine having two telnet sessions open, a news session open, reading your mail, and FTPing some gif's from MIT :-) all at the sametime. It's astounding... Hope that helps. Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
time@ice.com (02/13/91)
In article <27B86646.1477@intercon.com>, kdb@macaw.intercon.com (Kurt Baumann) writes: > In article <1991Feb9.195637.26171@DMI.USherb.CA>, protocom@terre (protocom-Laurent turcotte) writes: > > (2) is the question of speed which would be faster (SLIP/FTP, XMODEM or KERMIT) > > > > The benifits far out weight any problems with speed. It really depends on the type of > modem you are using, and other factors, but speed is usually very good with SLIP, > I don't complain and believe me I complain a lot when I have to wait. :-) > > > (3) which is the most flexible? I think SLIP since you can almost do anything > with IP but send me your opinions. > > SLIP is definatly the most flexable. Imagine having two telnet sessions open, > a news session open, reading your mail, and FTPing some gif's from MIT :-) all > at the sametime. It's astounding... I think this is a little misleading. Even with a 9600 baud connection with MNP, running SLIP based TCP with *all* of the things you listed going on would be excruciatingly slow. I think SLIP is wonderful for specific tasks, such as mail delivery and ftp, but in terms of moving a file from one machine to another, XMODEM is both fast and widely available. ZTerm is even faster. An ftp over SLIP will not even come close to these tools. On the other hand, you can't XMODEM your way into sumex-aim! I think it is important for users to work with the most efficient tools available. If the time wasted moving from one application to another (cheap in MF) is too much, then by all means deal with the delays in the protocol, but I don't this is often the case. 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
markb@unix386.Convergent.COM (Mark Beyer) (02/14/91)
In article <1CE00001.ouf99a@tbomb.ice.com>: > ... but in terms of moving a file from one machine to another, >XMODEM is both fast and widely available. ZTerm is even faster. An >ftp over SLIP will not even come close to these tools. What is the technical reason that XMODEM and ZTerm are faster ? I'm not familiar with those protocols. Thanks. >tim. Mark -- Mark Beyer markb@convergent.com {uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb
time@ice.com (02/14/91)
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
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/15/91)
>First off, you must realize that TCP runs ontop of UDP on top of IP. No. TCP and UDP (and ICMP, for that matter) are peers, both layered on top of IP. >(I believe this layering is not *mandatory* but is common place). It is mandatory, in the sense that every valid TCP packet is contained in a valid IP packet; ditto for UDP. It is not mandatory in the sense that someone with strange ideas might not implement things as separate layers. The rest of what you say looks ok, if you everywhere replace "UDP" with "IP". >I do not believe FTP adds any overhead in the data stream. The overhead it adds to the data stream varies from negligible to none; the CPU overhead on both ends of the connection can be significant if one is doing ASCII mode transfers. >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! Right; you pay for the flexibility of TCP/IP with overhead; you pay for the efficiency of ZMODEM with very, very limited functionality. >Again, pick the best tool for your job. Right again. FTP over SLIP is a silly thing to use if all you want to do is transfer files. If you also want to login or use mail or news, then SLIP is the way to go. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
resnick@cogsci.uiuc.edu (Pete Resnick) (02/15/91)
time@tbomb writes: >First off, you must realize that TCP runs ontop of UDP on top of IP. Nope. TCP and UDP are seperate and each is "built on top of" (to use your terminology) IP. A TCP or UDP packet is wrapped in IP, which is in turn wrapped in whatever low-level network protocol is needed (e.g. Ethernet). I am not sure what (if anything) serial lines need. Either way, the "overhead" is not as bad as you say. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD