In article <[EMAIL PROTECTED]>, Steve Holden wrote: >> I don't think that's right. You are confusing the PSH flag (which is >> basically unused in Unix networking I think) and the URG flag (which >> is extremely rarely used, but is indeed used by FTP to get abort >> requests to 'jump the queue' as it were). > > Nope.
I'm sorry, but you're definitely mistaken. > The URG flag indicates that a packet contains out-of-band data, > whihc is what you describe above. "out-of-band" is just way the sockets interface slightly mis-describes it. Either way, it causes (in Unix) the FTP server process to receive a SIGURG; the signal handler sets a flag and the data-transfer loop stops. > The PSH flag indicates that the data stream must be flushed right > through to the other end. That's sort-of true, but irrelevant. The PSH flag, when received, means that the networking layer should unbuffer any data and ensure it is released to the receiving application. *However*, BSD sockets never wait before allowing the application to receive incoming data, so the incoming PSH flag is unnecessary and ignored. In addition, the sockets interface simply doesn't provide a method for applications to set the PSH flag on output. The networking system simply sets the PSH flag by default whenever the output buffer empties. > This is essential for interactive protocols such as FTP: without it > the server has no way to know that the client has sent a complete > command, and vice versa. I'm afraid that's completely wrong. The FTP server knows it has received a complete command because it sees the CRLF sequence in the data stream. I must admit it's refreshingly unusual to find someone who is more familiar with TCP/IP as described theoretically in the 1981 RFCs than the realities of the sockets interface ;-) -- http://mail.python.org/mailman/listinfo/python-list