Re: Socket weirdness

Hi William,

Here are a few questions that I still cannot answer:

1. If shutting down receive on a socket blocks incoming data, does the socket respond with anything when data is actually sent from
the peer?
2. What actually is sent; ACK or RST, ACK and RST, nothing, or something else?
3. Is the response immediate?
4. Does a blocking Send wait for a response before returning to the caller?
5. If Send does wait for a response, why doesn't the initial call to Send fail when RST is received (this question is derived from
how I've understood Alan's explanation thus far)?
6. Does BeginSend wait for a response before returning to the caller (I hope not)? Does EndSend wait for a response?

I responded to your OP because I knew how that behavior could be explained in general terms, through simple experimentation. Now
that we gone down a more technical road I'm intrigued, yet confused.

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.

I think we are still talking about the same thing. RST makes it way back to
the client on an ACK. However, you may not see that ACK until after 1 or 2
sends. I "think" tcp can send two packets without ACK, but then must wait
(correct me here if wrong) for ACK before sending more. But eventually you
will get the ACK with the RST set and the next send/receive will fail.

That's where I'm confused. Alan's explanation does not mention ACK, except when he stated the following early on in his response:

The flags SYN, ACK, PSH, and
URG have no part to play here.
<snip>
Then eventually a packet comes from the peer, and that will
contain data, so the server responds RST: 'I can't handle that'

Yours and Alan's sound like competing explanations to me. I'm trying to understand how this works, techincally speaking, but I'm
confused as to which explanation is correct. Or are they both correct, but only partial answers?

| Interesting that the RST made it back into the client stack but
ConnectionReset is returned only on every subsequent request.

I did not follow you here.

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?

I assumed that the peer was aware of the reset immediately after the first send, as per Alan's comments above. If that is true, I'm
not sure why the first Send doesn't just fail with ConnectionReset and not just subsequent Sends.

I guess I'll have to do some reading on my own. If ever I can explain this phenomena I'll post my findings.

It will fail if it was received. But in our case it not (and can not) be
received until after the first send, because it is set in the ACK of that
first send. But I may already have did another Send before first ACK is
processed, so I may see it on second or third send. If we always do the
"proper" shutdown both sides, then none of this matters and all should work
fine:
1.. Finish sending data.
2.. Call shutdown() with the how parameter set to 1.
3.. Loop on recv() until it returns 0.
4.. Call closesocket().
Cheers.
--wjs

Understood, but I don't see how that applies to the OP or this thread. I thought we were trying to address problems that have been
identified with the unorthodox, but possible, scenario for using sockets whereby a peer attempts to shutdown receiving without a
higher-level protocol to notify its counterpart of such an occurrence. A standardized shutdown sequence seems a bit off-topic to me
and does not address the problem at hand.

Sorry if I'm nitpicking ;)

--
Dave Sexton


.

Relevant Pages

  • Re: Socket weirdness
    ... Anyway, if the application on one device does Shutdownthen if a packet containing data is received from the peer on that connection, then that is an not a valid packet and a packet with the RST bit set is sent clearing down the connection. ... In TCP there is simply *one* type of packet, this is unlike HDLC, which carries data in 'I' frames, has ACK frames which it calls 'RR', and lots more. ... And receiving a segment containing data is not valid where the local application has done shutdown). ...
    (microsoft.public.dotnet.framework)
  • Re: How TCP handle (RST,SYN) at initial connection establishment
    ... > SYN) or (RST, ACK) or simply RST upon receiving of any ... > SYN request towards victim server. ... > acceptable if the ACK field acknowledges the SYN." ... The "client", during the three-way handshacking, starts in CLOSED state, ...
    (Security-Basics)
  • Re: Socket weirdness
    ... |>>> with a packet with the RST flag set. ... Again the client application can be doing sends, ... you may not see that ACK until after 1 or 2 ... will get the ACK with the RST set and the next send/receive will fail. ...
    (microsoft.public.dotnet.framework)
  • Re: Serial port failure
    ... with their Id and Ack in this format '0 Ack' To be certain that I ... response = p.readline ... except SerialException: ... lane = GetAck ...
    (comp.lang.python)
  • Re: TCP socket close problem
    ... So, indeed, the packets with the FIN and RST (and also, a preceeding ... ACK) are dropped by tcp_input. ... Since the server has not acked the FIN packet, ...
    (comp.unix.bsd.freebsd.misc)