Xref: utzoo comp.dcom.lans:1418 comp.protocols.tcp-ip:3666
Path: utzoo!attcan!uunet!lll-winken!lll-tis!oodis01!uplherc!nrc-ut!nrcvax!jt
From: jt@nrcvax.UUCP (Jerry Toporek)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip
Subject: Re: FTP server question
Message-ID: <1488@nrcvax.UUCP>
Date: 26 May 88 02:32:42 GMT
References: <535@interlan.UUCP>
Reply-To: jt@minnie.UUCP (Jerry Toporek)
Distribution: na
Organization: Network Research Corp.  Oxnard, CA
Lines: 22

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