From: Marc Soda <marcantoniosr@...>
Date: 2007-01-23T12:59:07+09:00
Subject: Re: Socket issue

On 1/22/07, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
> What you are seeing is in the nature of TCP.
>
> After the connection succeeds your server shuts down *its* end of
> the TCP session (i.e. it tells the client that it won't send any
> more data).  Since TCP is full duplex, the client-> server part of
> the connection is still up and running as far as the client is
> concerned.
>
> Your first write stuffs the data in a buffer and returns (with no
> error).  Shortly thereafter the kernel decides to actually transmit
> the data.  The server responds with a RESET indicating that it will
> no longer accept data on that TCP session.  The error is noted by
> the kernel and is reported to your client code on the *next* attempt
> to write to the socket (which is now in an error state).
>
> There is no one-to-one mapping of a write call on the socket to
> data transmission on the wire for TCP due to buffering. This is
> why the first write doesn't cause the transmit/detect/report of
> the error.
>
> Gary Wright
>
>
>
>
>

Gary,

First, thanks for your answer.  I agree with you, however, my
understanding was that after the client side kernel flushes it's
buffers from the second send(2) (the first send after the server dies)
the server would send a RST back.  If I were to go about other
processing and not even touch the socket again I should still receive
and SIGPIPE.  Is this not true?

Thanks for your time.
Marc