Użytkownik Eddie Lascu <[EMAIL PROTECTED]> napisał: >Hi Marek, > >To answer you here are some observations that I would like to make. > >1. TCP (as opposed to UDP) guarantees you the delivery of the > message. This is consistent in Win32 and I have never had any > problems in the past.
No, no protocol can guarantee message delivery (in a distributed network). TCP can guarantee delivery in that sense that once the remote endpoint *acknowledges* data (at the TCP layer), you know it has received the data *correctly* and *in the right order* (not delving into details, e.g., whether checksums in the TCP/IP protocol suite are reliable). It does not mean that when you perform a successful Send(), you will have your data delivered. Send() just asks the TCP layer to try to send the data. That's all. After some time, transfer will be initiated. After some even longer time, some or all of the data may be acknowledged by the receiver. Or not. If someone unplugs or cuts a cable or there is congestion in the network or something else happens, some or all of your data may get lost. >2. I can understand that the Send function succeeds in sending > the message while the server prepares to close the socket. In > this case the server is responsible to clear the buffer before in > shuts down. However, in the small example that I have created, > the second Send on the client side is called way after the Server > socket was shutdown (both for sending and receiving) > and closed. As I said in my previous e-mail, I believe that Send() *could* and *should* throw an exception. I know that the socket has been already closed. What I was trying to say is that one cannot rely on Send() at all - so, perhaps it was some optimization not to throw the exception. If you follow Send() with another Send(), you will get the exception. About "clearing the buffer before shutting down", read below. >3. Just a side note, I also observed that if the client end, instead > of sending a second message, shuts down its socket and then > tries to reconnect it, the reconnection is successful. All these > while the Server socket was closed. Since I still believe it has > something to do with the socket not being garbage collected... <stress>This has nothing to do with GC!</stress> The server closes 'handler' - the socket it has created to handle this particular TCP endpoint. But the main server socket, the one that listens for TCP connections, 'listener', remains open. The behavior observed suggests that the server accepts a remote connection in the background before its code calls Accept(). Of course, you probably could GC-collect 'listener' but what for? Call Close() on it and the server will be definitely gone. If you need more info about how TCP works, you can either refer to a book about it or *carefully* read the docs about Socket stuff - I believe it clearly states that almost nothing is guaranteed. And, as I said previously, even if the remote system has received your data, it does not mean that the server (the application) has read the data. For example, the server could implement a policy that sockets are closed after some time (or, some silent time); it is possible it will not read and process data received just when it is about to close the socket. Marek =================================== This list is hosted by DevelopMentorŽ http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
