Xref: utzoo comp.dcom.lans:1396 comp.protocols.tcp-ip:3628
Path: utzoo!attcan!uunet!husc6!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: FTP server question
Message-ID: <22806@bu-cs.BU.EDU>
Date: 23 May 88 21:07:39 GMT
References: <535@interlan.UUCP>
Distribution: na
Organization: Boston U. Comp. Sci.
Lines: 37
In-reply-to: backman@interlan.UUCP's message of 23 May 88 16:24:36 GMT


>	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