backman@interlan.UUCP (Larry Backman) (05/23/88)
[] An FTP puzzle for the protocol whizes on the net. Consider the following two sniffer packets from a long trace: Packet 1 contains a FTP servers Hello message without a CR/LF. Packet 2 contains the CR/LF. RFC 959, section 4.2 of the DDN protocol handbook Page 2-773 and 2-774 clearly state: "A reply is defined to contain the 3 digit code, followed by Space <SP>, followed by one line of text (where some maximum line length has been specified), and terminated by the Telnet end of line code." At first glance, the FTP server is at fault. However, in their defense, FTP uses TCP, a stream oriented protocol, to ensure reliable delivery. This means that the data from a stream can come out as one single packet, or in the worst case, dribble out as a stream of single bytes. So in the second case, the split of the FTP message, and the TELNET CR/LF is not so bad. Needless to say, something bad happens on my end as a result; nothing that I can't hack around, but before doing so, I thought the problem was interesting enough to solicit some other opinions, Larry Backman Micom - Interlan - - - - - - - - - - - - - - - - Frame 63 - - - - - - - - - - - - - - - - - SUMMRY Delta T Destination Source Summary 63 0.0291 02070100B550 080014302203 FTP R PORT=1230 220 MIND FTP server (EXOS Version 4.5 Mon Sep 8 08... FTP: ----- FTP data ----- FTP: FTP: 220 MIND FTP server (EXOS Version 4.5 Mon Sep 8 08... FTP: ADDR HEX ASCII 0000 02 07 01 00 B5 50 08 00 14 30 22 03 08 00 45 00 .....P...0"...E. 0010 00 71 66 A9 00 00 3C 06 15 02 80 A6 80 83 80 A6 .qf...<......... 0020 81 0C 00 15 04 CE 03 12 DD C2 00 A1 51 42 50 18 ............QBP. 0030 10 00 16 27 00 00 32 32 30 20 4D 49 4E 44 20 46 ...'..220 MIND F 0040 54 50 20 73 65 72 76 65 72 20 28 45 58 4F 53 20 TP server (EXOS 0050 56 65 72 73 69 6F 6E 20 34 2E 35 20 4D 6F 6E 20 Version 4.5 Mon 0060 53 65 70 20 38 20 30 38 3A 34 31 3A 31 37 20 50 Sep 8 08:41:17 P 0070 44 54 20 31 39 38 36 29 20 72 65 61 64 79 2E DT 1986) ready. - - - - - - - - - - - - - - - - Frame 64 - - - - - - - - - - - - - - - - - SUMMRY Delta T Destination Source Summary 64 0.0001 02070100B550 080014302203 FTP R PORT=1230 <0D><0A> FTP: ----- FTP data ----- FTP: FTP: <0D><0A> FTP: ADDR HEX ASCII 0000 02 07 01 00 B5 50 08 00 14 30 22 03 08 00 45 00 .....P...0"...E. 0010 00 2A 66 AA 00 00 3C 06 15 48 80 A6 80 83 80 A6 .*f...<..H...... 0020 81 0C 00 15 04 CE 03 12 DE 0B 00 A1 51 42 50 18 ............QBP. 0030 10 00 58 00 00 00 0D 0A 30 20 4D 49 ..X.....0 MI
bzs@bu-cs.BU.EDU (Barry Shein) (05/24/88)
> An FTP puzzle for the protocol whizes on the net. Consider the > following two sniffer packets from a long trace: > > Packet 1 contains a FTP servers Hello message without a CR/LF. > Packet 2 contains the CR/LF. ... > At first glance, the FTP server is at fault. However, in their > defense, FTP uses TCP, a stream oriented protocol, to ensure > reliable delivery. This means that the data from a stream can > come out as one single packet, or in the worst case, dribble out > as a stream of single bytes. So in the second case, the split of > the FTP message, and the TELNET CR/LF is not so bad. > Larry Backman Unless I misunderstand you there's nothing wrong with the server, it's not unusual for a system to produce such a message in two (or more) writes and each end up in its own packet, how is the underlying OS supposed to know to wait for one more write before shipping the data from the first write? (using UDP the server application might indeed have to control such behavior by buffering its own writes to "packet" boundaries [even that's only "virtual" packet boundaries, fragmentation could still show up on the wire, which sounds like what you're measuring, but should be transparent to the client], but that's not the issue here.) Your "defense" of the server is correct. Sounds like your client is imposing record boundaries on a TCP stream where it shouldn't, you should be able to read until you see CR-LF (or EOF or ERROR) w/o regard to how the data was sent. Consider it a bug in the client, possibly at the application level (ie. i bet they're assuming that the entire record will arrive in one read operation rather than looping reads until the CR-LF shows up.) -Barry Shein, Boston University
romkey@kaos.UUCP (John Romkey) (05/24/88)
Any code which uses TCP which expects TCP to preserve read()/write() chunking of data (if that's even the abstraction you're using to communicate with TCP) across the network is BROKEN. TCP doesn't preserve this information, and anything that expects it to is asking to lose very loudly. Even if the application writes a whole block of data in one write(), there may easily be conditions beyond the control or detection of the client or server that would cause the TCP to break it up into several pieces which the other side would see dribbling in as smaller parts rather than the whole block that was originally written. -- - john romkey UUCP: romkey@kaos.uucp ARPA: romkey@xx.lcs.mit.edu ...harvard!spdcc!kaos!romkey Telephone: (617) 776-3121
mhw@wittsend..LBP.HARRIS.COM (Michael H. Warfield) (05/25/88)
In article <535@interlan.UUCP> backman@mercury.UUCP (Larry Backman) writes: > > Packet 1 contains a FTP servers Hello message without a CR/LF. > Packet 2 contains the CR/LF. > > RFC 959, section 4.2 of the DDN protocol handbook Page 2-773 and 2-774 > clearly state: > > "A reply is defined to contain the 3 digit code, followed > by Space <SP>, followed by one line of text (where some > maximum line length has been specified), and terminated by the > Telnet end of line code." > > > At first glance, the FTP server is at fault. However, in their > defense, FTP uses TCP, a stream oriented protocol, to ensure > reliable delivery. This means that the data from a stream can > come out as one single packet, or in the worst case, dribble out > as a stream of single bytes. So in the second case, the split of > the FTP message, and the TELNET CR/LF is not so bad. > More to the point is the fact that, to an application, data on a tcp/ip connection is a structureless stream of bytes. Any structuring is imposed by a higher level (i.e. ftp client / ftp server). This implies that tcp/ip packet boundries have no significance to the application (ftp) and may not even be discernable in many implimentations. This applies even if there is a PUSH flag on the tcp/ip packet. It does not, of course, apply if an urgent flag is on the data, indicating the last byte of the packet is an URGENT boundry. But, then again, ftp does not use that flag for anything. RFC 959 concerns the ftp protocol itself and does not relate to tcp/ip packets or structuring. --- Michael H. Warfield | gatech.edu!galbp!wittsend!mhw (404)-329-8139 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it! Michael H. Warfield | gatech.edu!galbp!wittsend!mhw (404)-329-8139 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
karn@thumper.bellcore.com (Phil R. Karn) (05/25/88)
While it is certainly true that a client that expects any sort of relationship between TCP segments and logical messages is broken, I wouldn't let the server get off the hook that easily. Why should it take two packets to send what should go in one? In this, the first year AJ (After Jacobson) I would think people would be a little more aware of such inefficient TCP behavior. :-) Phil
jt@nrcvax.UUCP (Jerry Toporek) (05/26/88)
In article <535@interlan.UUCP> backman@mercury.UUCP (Larry Backman) writes: > [...] > At first glance, the FTP server is at fault. However, in their > defense, FTP uses TCP, a stream oriented protocol, to ensure > reliable delivery. This means that the data from a stream can > come out as one single packet, or in the worst case, dribble out > as a stream of single bytes. So in the second case, the split of > the FTP message, and the TELNET CR/LF is not so bad. > > Needless to say, something bad happens on my end as a result; nothing > that I can't hack around, but before doing so, I thought the problem > was interesting enough to solicit some other opinions, You got it all right. Any piece of stream-based software that makes any assumption about what it is going to get back from a read is asking for trouble. -- ====================================== `` '' =============================== Jerry Toporek <`@-@'> Network Research Corp. ( > ) 1620 Federal Ave. #2 jt@NRC.COM \~/ LA, CA, 90025, USA jt@nrcvax.UUCP (213) 479-6436