On 2/9/06, Jeff Pang <[EMAIL PROTECTED]> wrote: > Thanks for Bob and Jay.I just want to know,when 'close' is called,what should > happen under the tcp protocol stack. > The question I really want to know is,when the server see the EOF coming from > the client,while the server-code doesn't call the 'close',should it send the > second FIN to the client or not? > to Bob: the difference between 'close' and 'shutdown' is not only that by you > said,but the 'shutdown' should affect all child process,while 'close' doesn't. > > -----Original Message----- > >From: Bob Showalter <[EMAIL PROTECTED]> > >Sent: Feb 10, 2006 2:12 AM > >To: Jeff Pang <[EMAIL PROTECTED]>, beginners@perl.org > >Subject: Re: whereis the socket mailing list > > > >Jeff Pang wrote: > >> The question I want to know is,when the 'close()' call happened,if it > >> should generate a 'FIN' and send it to another end?If it's true,then at > >> the server end,when it receive the 'EOF' coming from client,it can delay > >> for some time to call 'close()',so the 'FIN' should not be sent to client > >> immediately,is it? > > > >Once you call close(), you're done with the connection. The kernel > >handles the various packets associated with terminating the connection. > > > >When the server sees EOF, it can call close() immediately if it doesn't > >need to send any more data. Again, the kernel will handle the details. > > > >shutdown() is only needed if you want to tell the other side you're done > >sending, but you need to be able to keep receiving data. > > > >If you're interested in learning more, I *very highly* recommend you buy > >and read Stevens' "Unix Network Programming, Volume 1" > >(http://www.amazon.com/gp/product/0131411551). >
I stand by everything I said above, and Bob's advice to pick up Stevens--it's a very useful book--this is getting a little bit beyond the scope of this, or any other, beginners list. If you really want to understand the nitty gritty of TCP, rfc793 is available many places online. The close sequence spec starts on page 30-something, I think. On any OS you're likely to encounter, though, you should never have to deal with the protocol layer directly. Connection estableshment, closing, ACKs, and even packet formation should be handled by the kernel or wherever the your OS hides its TCP stack. Your involvement ends when your user-space client or server issues whatever the appropriate close() system call is for your platform, either by hand or using a standard function libary. Closing can actually be complicated, from a scheduling point of view, because queued data must be sent, etc. For reference, a typical client-initiated close would look something like this: 1) Client issues write for last data segment, OS TCP scheduler forms packets and adds to queue. 2) Client issues close() system call and blocks. 3) Client TCP flushes queue and appends FIN. 4) Client TCP sends FIN and enters FIN-WAIT-1 (continues to read, but won't accept writes, and won't send packets other than FIN/ACK), server TCP enters CLOSE-WAIT (doesn't really effect behavior, but it knows the other end wants to close). 5) Server TCP ACKs the FIN, client TCP enters FIN-WAIT-2 (looks a lot like FIN-WAIT-1) 6) Server process stops writing to the socket, either becuase it's polling the client, or because it's finished with what it was doing, and issues close() system call. 7) Server TCP appends FIN to the queue. 8) Server TCP flushes the queue, waits for all packets to be ACKed. 9) Server TCP sends FIN. 10) Client TCP enters TIME-WAIT and ACKs FIN. 11) Server TCP closes socket. 12) After 2x timeout, Client TCP exits TIME-WAIT and releases socket. That's one version, there are variants if the server initiates the close, or if there's a simultaneous close. From a programming client/server programming standpoint, though, this is all academic. we don't have direct access to the TCP layer (unless we're looknig at ntop out put trying to debug a connection); we only ask the system to bind us to a socket, and the kernel takes acre of the rest. The important thing to programmers, though--at least people who aren't actively hacking and OS--is at what point the system passes a return value for the close() system call back to the calling process. This is OS-dependant, but should be around step 10 for the client, 11 for the server. HTH, -- jay -------------------------------------------------- This email and attachment(s): [ ] blogable; [ x ] ask first; [ ] private and confidential daggerquill [at] gmail [dot] com http://www.tuaw.com http://www.dpguru.com http://www.engatiki.org values of β will give rise to dom!
