solensky@interlan.interlan.COM (Frank Solensky) (11/08/89)
Is there any specific requirement that reply codes sent over an FTP control connection be synchronized with the packets transmitted over the data connection? I've checked through both RFCs 1123 and 959 a few times and have found quotes that imply that they both must be in synch and aren't expected to be in synch but haven't come up with anything conclusive. (However, many in the former category seem to be based on an assumption that the phrase "close(d) the connection" == "send(/received) a FIN"). When some client FTP program is being used to pull a file across the net, a time-sequence diagram of what is occuring is this (stream data connection, using SO_NODELAY): FTP client net traffic FTP server ---------- ----------- ---------- GET file C-> RETR file (WIN > 0) ds = socket() opens a socket D-> SYN,WIN=0 (et al) send() file close(ds) C<- "226 closing connection" message D-> WIN > 0 D<- data D<- FIN What I'm looking for is some passage in either RFC or some other source that states this is or is not acceptable. TIA. Frank Solensky Racal InterLan or
amanda@intercon.com (Amanda Walker) (11/13/89)
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 <amanda@intercon.com> InterCon Systems Corporation -- @