Re: Socket weirdness

| I understand that this limitation is indeed in the TCP protocol itself.
What I don't understand is why. I still think it would be
| nice if the first send would fail since the RST flag is in the stack
anyway. If you look at William's example with my revisions,
| you'll see that each Send, including the call to BeginSend, is executed
sequentially. If RST is at the top of the stack before the
| next call to Send then why can't the first call to Send (or BeginSend)
just fail instead of returning to the caller?

AFAICT, RST is not "seen" by the client until the first ACK to client *after
a Shutdown.Receive by the server. So I assume you may not even see the RST
until the 3rd send depending on speed, etc. Thing I don't understand yet is
why RST is not set in the header of outgoing data if the server does a send
after Receive is closed? Or why the server even lets you do a send after a
Shutdown.Receive if ultimately it forces both sides of the client down
anyway?

Note: I have no compelling reason I want to do this, other then experiments
and noting behavior and exceptions. However it would seem like a use for
closing receive on server would be a stock ticker app. The client sends a
single request message to server. The server verifies and closes Receive -
as if to say "I do not expect any more "data" messages (i.e. not control
packets) from client and will be error.". And then server just streams data
to client one-way and then closes send after requested number of stocks or
some N factor of stocks or time and closes socket. The client reads until
0, then just closes socket. Naturally, it is easy to refactor this to do
normal shutdown behavior.

--wjs


.

Relevant Pages

  • Re: Socket weirdness
    ... If RST is at the top of the stack before the ... RST is not "seen" by the client until the first ACK to client *after ... a Shutdown.Receive by the server. ... some N factor of stocks or time and closes socket. ...
    (microsoft.public.dotnet.framework)
  • Re: TCP socket close problem
    ... use for the RST anymore - the seq number of those RSTs is taken from the ... acceptable by the server. ... probably most likely at the client end, ... Client asks for something that the server will send in 2 packets. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Socket Connections - never seem to close
    ... > explicitly invoking the java.net.Socket.closemethod, the Server ... > socket connections in the ESTABLISHED state, whereas on the client ... > end 'netstat' shows no trace of the socket connections. ... abortive close segment - RST rather than FIN. ...
    (comp.sys.hp.hpux)
  • Re: Question regd timestamp option
    ... > RST Following this RST, the client comes back in lets say around ... Now if you open a second connection, while things are still OK, do you see the ... connections to the server? ...
    (freebsd-net)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)