Re: Socket weirdness

Hi Alan,

Excellent response. See inline:

Eeeeh. I hoped to clear things up in my posting; looks like I didn't quite succeed. :-)

Lol. It's hard to explain all of TCP in a single post.

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?

(Just to note firstly, doing Shutdown(Receive) alone/initially is very very very rare, Close/Shutdown(Both), or Shutdown(Send)
later followed by Shutdown(Receive) is very much more common. And if a particular application/session layer protocol implied that
one peer should do Shutdown(Receive) then it would not be valid for it to then have the other peer send data!)

Fair enough. I do understand the rarity of the operation under scrutiny. I'd like a complete understing of TCP and the ability to
shutdown Receive only is part of the protocol (and, not to mention, the topic of this thread :)

Anyway, if the application on one device does Shutdown(Receive) then 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.

Understood (from Goran's post as well).

2. What actually is sent; ACK or RST, ACK and RST, nothing, or
something else?

Firstly, just to be absolutely clear, there is no such thing as an ACK packet, or a RST packet, or a SYN packet, etc. In TCP
there is simply *one* type of packet, this is unlike HDLC (and its children), which carries data in 'I' frames, has ACK frames
which it calls 'RR' (Receiver Ready), and lots more. :-( Unfortunately its also often those such terms that are used by our
teachers...

I don't know anything about HDLC, and being an autodidactic anything that I don't undestand about TCP up until now is my own fault
:)

Anyway, TCP's header is always the same format. It contains some numerical fields e.g one for the sequence number, has a set of
flags: URG, ACK, PSH, RST, SYN and FIN, and finally it optionally carries some data. So (to be very correct) we can have "a
packet with the ACK bit set", but no such thing as a "ACK packet". Now often in reality we generally call a packet with no data
and the ACK bit set as an "ACK packet" but it can confuse...

Thanks for clearing that up. Also, the wikipedia.org article (link in a previous thread of mine) contains a nice little chart of
the TCP header and the meaning of each section of bytes.

So in the case above, a packet with the RST bit will be sent. I'm not sure whether the ACK bit will be set, I'd have to go and
read the specification to be sure, and I'm not sure that it matters particularly...

Understood now. RST is sent; ACK doesn't matter since it would be in the same header anyway. What's important is the RST (and ACK
probably shouldn't be set, for that matter)

3. Is the response immediate?

Err to what? :-)

To the peer that sent the data! I was leading in to my next question about whether Send blocked for that response because I assumed
the answer to this question was "yes"...

The server 'immediately' sends a RST when it gets any packet that is not valid. And receiving a segment containing data is not
valid where the local application has done shutdown(receive)). Of course there is time for both of those packets to cross the
network.

And as we note below, a send is _not_ immediate on the application calling send (or it returning etc)...

Understood now (from your response below as well). There is an inherant asynchronicity in TCP due to network latency and,
therefore, RST is sent immediately but might not be received by the peer before another Send, even if the peer only calls Send in a
synchronous manner.

This leads me to believe that our test code in this thread does not accurately represent the behavior of a socket in all possible
circumstances. The console output shows that the second Send will always raise an error since it received the RST, however, that
might not be the case in a real world application. (Goran tried explaining this in his illustration but he failed to mention
whether his model was synchronous or asynchronous, and without this new knowledge of mine that Send does not block for a response, I
assumed he was talking about an asynchronous model only.)

4. Does a blocking Send wait for a response before returning to the
caller?

No. It just adds data to the buffer and returns. (Ignoring here what happens if the buffer becomes full...) The TCP protocol
layer then decides when to take a segment's worth of data and send it in a packet. In general we should consider the two as
independent.

Isn't it the Nagle algorithm, not the TCP protocol, that determines what a "segment" actually is and when it should be sent?

So it seems that Send blocks when it has to load data into an overflowing buffer [Also: Peter Duniho's response to William's
question in a branch of this thread] and not for a response from its peer. This reallly confused me since I always assumed Send
waited for a response and BeginSend didn't.

This makes me change my outlook on TCP in general. I always thought TCP provided "Control' over the flow of information on its own
connection, but now I think that "Control" in "Transmission Control Protocol" is referring to the fact that TCP is used commonly to
control the flow of information on a higher-level protocol that involves other connections, such as with a video game that uses UDP
to transfer data, or as with an FTP data connnection that is independant of the "Control" connection. Is that correct or does
"Control" mean something else that I'm unaware of, such as an improvement on an ancestor protocol perhaps?

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)?
It doesn't. This might be where the confusion lies. :-(

Yep, it was one of the sources of confusion. It's not anymore. This thread contains a few answers to that question, but none have
clearly defined whether or not a blocking Send blocks for the RST, which I needed to know first before I could undertstand anything
else. Thank you for clearing that up. I guess that those who already understand TCP on the protocol level felt it was too obvious
of an answer to mention ;)

6. Does BeginSend wait for a response before returning to the caller
(I hope not)? Does EndSend wait for a response?
Neither.

Understood now from your answer to #5 as well.

I got lost following the messages in the text below, let me know what if anything that doesn't cover. :-)

Alan

You've answered all of the questions that I wrote so far. Sorry if I don't explain myself thoroughly enough. It's hard to ask
questions without fully understanding the terminology. Thanks for your help.

So it seems that the behavior I witnessed when using TCP/IP Sockets, with regards to the example in the OP, was a side effect of the
actual implementation and not a valid indication of the real behavior of TCP/IP. I can't say that I've used this mechanism in
production code but I have played around with it before and thought that I had the behavior pinned.

Again, I'm planning on reading more about TCP. RTFM is an acceptible response to any of my inquiries, but I do appreciate the help
:)

--
Dave Sexton


.

Relevant Pages

  • Re: How to Distinguish between a reset packet and a normal packet
    ... If you're talking about TCP, in a reset packet, the RST bit in the header ... You just have to check if the RST bit (which is, i think, the 142 bit in the tcp header) is 1 or 0. ...
    (comp.os.linux.networking)
  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • Re: jailed "system" needs IPV4 access
    ... see if the ACK flag is set on a tcp packet. ... the keep-state option just ... 00500 deny log ip from 192.160.1.0/24 to any in via dc1 ...
    (comp.unix.bsd.freebsd.misc)
  • Re: A question regarding MTU: how it can effect TCP performance + other queries
    ... Can you check if your physical NIC has TCP large send offload enabled? ... I can't think of anything for the UDP case however, that just seems strange to me. ... Are you grouping multiple UDP packets in one TCP packet? ... encapsulated within another TCP packet when passed to physical interface, while for UDP I am sending UDP packet encapsulated within TCP packet when passed to physical interface. ...
    (microsoft.public.development.device.drivers)
  • Re: Incoherent E-mails
    ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
    (alt.computer.security)