Re: Socket weirdness

Hi William,

[To summarize: we are discussing the mechanisms used by the TCP protocol when an end point shuts down receiving on the socket and
how that action affects its counterpart with regards to immediate changes in state and future changes in state]

| 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.

Your explanation seems to be accurate with respect to my test results and previous experience with sockets, however Alan's
explanation led me to believe that a different mechanism was in place. I am referring specifically to the following statement of
Alan's:

And at some point the first send now reaches the server, who responds
with a packet with the RST flag set. That then makes its way back
across the network. Again the client application can be doing sends,
and maybe some packets are sent too.
Then the RST reaches the client device, and works its way up through the stack.

In your test case there was no concurrent sending, so I assumed that on a blocking send with no concurrent activity that the RST
flag would "make its way back across the network" immediately from Alan's statements.

Boom! Now and only now
is ConnectionReset returned on every subsequent send or receive that the
client application makes.

Interesting that the RST made it back into the client stack but ConnectionReset is returned only on every subsequent request. My
previous statements were referring to this particular statement of Alan's. Why not just fail the initial send if the RST flag has
already been received, if in fact it is received?

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.

I can see how that might be useful to reduce the amount of network traffic since the client doesn't expect any responses anyway.
Unfortunately, the server has to send something at least once to find out that it shouldn't send anything again. Therefore, if you
design a protocol on top of TCP as such, your choices are then limited to either "all clients accept data" or "all clients do not
accept data" unless an error on the server is acceptable when trying to respond with data.

I was thinking that a forward-only connection could be useful to circumvent potential errors on a network topology that prevents
responses from being received by the counterpart. By shutting down the receive functionality the end point is saying, "Don't even
try to send any data 'cause I know that it won't get to me". Although I guess this won't work in TCP since the counterpart has to
Send data anyway in order to find out that little bit of information. And the sender won't know whether the first Send actually
succeeded or was just sucked up by the RST mechanism without a higher-level protocol in place to respond with an acknowledgement.

Does anybody know what the intended purpose was of the shutdown-receive flag when it was designed? i.e., What usage scenarios did
the designers have in mind?

I guess the usefulness of my participation in this discussion is moot without having read a substantial amount of the technical
specification for TCP. I'm just trying to understand what I've already experienced by means of a more technical explanation. If
I'm not making any sense please let me know.

Thanks for the link in your other response - I'll take a look.

--
Dave Sexton



.

Relevant Pages

  • Re: Socket switch delay
    ... both at the client and at the server (and why ... would you set the send buffer size to zero on a non-overlapped ... One glaring error is your client does ... So when you use a single socket, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Locking on async calls
    ... you must synchronize the entire SendMessage routine as an atomic ... operation to prevent mixed messages from being transmitted to the server. ... You are correct that read and write on the socket do not interfere with each ... If you want to handle multiple client connections from one server object ...
    (microsoft.public.dotnet.general)
  • Re: Design issue with WinSock/GetQueuedCompletionStatus
    ... delegate that to a shutdown routine called after all worker threads ... The application I've created is a server accepting connections on a few ... different TCP/IP ports and then lets the client run different commands. ... a TCP/IP socket can be closed for 2 different reasons: ...
    (microsoft.public.win32.programmer.networks)
  • Re: socket communication: socket doesnt connect
    ... Microsoft MVP, MCSD ... As far as your server code goes, ... accept the listening socket. ... Client client = new Client; ...
    (microsoft.public.vc.language)
  • Re: TCP server stop receiving new connections
    ... reset the event mask of your listening socket each time you ... I have a strange problem in my class library used by all our client ... server applications. ... incomming connections, but keeps current connections. ...
    (microsoft.public.win32.programmer.networks)