Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!intercon!amanda@intercon.com From: amanda@intercon.com (Amanda Walker) Newsgroups: comp.protocols.tcp-ip Subject: Re: FTP command/data synchronization Message-ID: <1547@intercon.com> Date: 13 Nov 89 01:26:49 GMT References: <8911071945.AA02611@interlan.interlan.com> Sender: news@intercon.com Reply-To: amanda@intercon.com (Amanda Walker) Lines: 35 In article <8911071945.AA02611@interlan.interlan.com>, solensky@interlan.interlan.COM (Frank Solensky) writes: > What I'm looking for is some passage in either RFC or some other source that > states this is or is not acceptable. By my reading of the RFC, this is fine, and I know from experience that it does indeed happen fairly often in the real world, and so from a pragmatic standpoint, I'd write my FTP client to deal with it if I were you :-). The central issue is that there is no synchronization between the two TCP streams (which are, after all, completely separate at the TCP level), and so buffering strategies can cause the individual packets to come out in weird orders. There are two ways to handle this in an FTP client, and which one you use depends on the I/O strategy you are using in general. - Blocking I/O (as in UNIX FTP): This one's easy--you just don't pay attention to the command connection (unless urgent data comes in, telling you to abort the transfer) until the data connection closes. The 226 message will just be buffered, and will be there waiting for you when you come back to the command connection. - Non-Blocking I/O (as in a client FTP I've worked on): If you're using non-blocking I/O and dealing with data as it comes in, you've probably got a big state table anyway; all you need to do is add more states to cover the various messages on the command connection coming in at any time, or maintain separate command & data states. Neither of these is terribly difficult if you're careful. -- Amanda Walker InterCon Systems Corporation -- @