Re: Socket weirdness

Hi Alan,

This is I presume what Dave meant when he said "you are basically setting up a wall"

That is what I meant. I was just speaking from experience, so I didn't want to make any technical assumptions using terminology
that I didn't fully understand.

However he wasn't quite correct in saying 'It would be nice, however, if the first send failed as well but I see that from the
docs this "design" was by choice.' The software writers have _no_ choice in this, the TCP protocol doesn't allow such a behaviour

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? And what kind
of "connected" protocol is TCP anyway if it acts "disconnected" in so many ways? And if shutting down Send behaves in some manner
shouldn't shutting down Receive behave in a similar manner if just to preserve consistency in the protocol?

You've posted some interesting stuff. I'm going to have to read about the protocol itself now to fully appreciate it. Thanks a
lot!

I'm thinking about starting here:

TCP on Wikipedia.org
http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Any suggestions on other reading material for this weekend?

--
Dave Sexton

"Alan J. McFarlane" <alanjmcf@xxxxxxxxxxxxxxxxx> wrote in message news:450fd11d$0$2700$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In article news:O1OxDg52GHA.1588@xxxxxxxxxxxxxxxxxxxx, William Stacey
[MVP] wrote:
"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:O6rzGL42GHA.5048@xxxxxxxxxxxxxxxxxxxxxxx
[...]
The other thing we discover here via imperitive evidence is that
shutdown.receive will never be sent by server unless it can
piggyback on an ACK reply or an outgoing message. Something I must
remember. Cheers.

I haven't tried using an outgoing message. Did you test that?

I guess the bit is not set in a send either - only the ACK. So I
guess that means you must always do at least two sends (at the
client) before you will notice a shutdown receive at server.

What "bit"? There is *no* flag for Receive_Closed! There are two relevant flags: the FIN flag which means Finished_Sending, and
RST, which means Reset: in general means 'I've no such connection, please delete that connection from your list'. The flags SYN,
ACK, PSH, and URG have no part to play here.

So when the server does "socket.Shutdown(SocketShutdown.Receive);", it can't do anything based on that. It just sits dumb waiting
for another action. Then eventually a packet comes from the peer, and that will contain data, so the server responds RST: 'I
can't handle that'. This is I presume what Dave meant when he said "you are basically setting up a wall": no signal, just that
any data received will crash into the wall. However he wasn't quite correct in saying 'It would be nice, however, if the first
send failed as well but I see that from the docs this "design" was by choice.' The software writers have _no_ choice in this, the
TCP protocol doesn't allow such a behaviour.


So, remembering that the server has sent nothing after the local application did SocketShutdown.Receive. Lets look now at what
happens from the aspect of the client side. Remember that TCP makes no guarantee of maintaining send boundaries etc. So the
client could buffer up multiple send before deciding to send a packet, that packet then works its way across the network,
meanwhile the client application could be doing more sends, which are likely buffered up, and maybe sent at some point, and again
the client application could be doing more sends, and even blocking or non-blocking :-,) on a receive.

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. Boom! Now and only now is ConnectionReset returned on every
subsequent send or receive that the client application makes.


So two things about TCP, firstly SocketShutdown.Receive cannot be signalled. That's a very rare and odd case that there's no need
to cover it: 'I've more to send, but I don't want to hear any error responses from you'! Odd, whereas the opposite is common:
'I've now finished sending all I have, but I'm still listening for any feedback you wish to send me.'

Secondly, that *errors* on the connection can only be signalled on later send/receive calls. Errors are only apparent after
buffered data has been sent and a error response has been received from the server across the network, or if the network is down
for instance that 'I've had to retry sending data five (say) times and I've now given up'.


Note that SocketShutdown.Send, is signalled with flag FIN, which is 'data' so it is sent in a packet with or after the last byte
in the send buffer has been sent. To get an error earlier some protocols send regular packets to say 'are you alive?' (for
instance HDLC, IrDA, SNA, SPX (?my memory is fading)). But due to the philosophy of TCP, that, to try and ride over network
failure do not send any packets unless there's data to be sent, no such packets are sent.

I recommend that you put your server and client on different machines and look at the traffic between then with a network
analyser. What's happening below the APIs can then be seen.
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.


.

Relevant Pages

  • RE: Printing from Win9x clients stops
    ... Open Server Management. ... then right-click the name of the computer running Windows Small Business ... >From the client computer: ... The Select Network Component Type ...
    (microsoft.public.windows.server.sbs)
  • RE: Printing from Win9x clients stops
    ... The printers with 9x drivers on the server appeared automatically in the ... > then right-click the name of the computer running Windows Small Business ... > From the client computer: ... The Select Network Component Type ...
    (microsoft.public.windows.server.sbs)
  • [REVS] Backdoor Spotcom Analysis
    ... Spotcom is a backdoor client application that allows a hacker to control ... The server IP address is hard-coded in ... msrsvp.exe accepts a couple of command line arguments. ... the packet payload. ...
    (Securiteam)
  • Re: Daily Server Report (Critical Errors, Event ID: 537)
    ... Does this issue happen on client workstation or server? ... Does your server and all clients' workstation work well now? ... issue in your Network? ...
    (microsoft.public.windows.server.sbs)
  • Re: Small business thinking about backing up data, having a server and 2-3 users - is SBS200
    ... is networked to the Master with a crossover network cable. ... Master on the Master PC and Client on the Slave pc. ... Since this machine is a server is should handle the requests ok ... Most real firewall appliances have HTTP and SMTP proxy services that allow ...
    (microsoft.public.windows.server.sbs)