> 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.
But how can the remote endpoint acknowledge the data if it was closed already (or at least it has been asked to close, for that matter)? You see, here is the problem in the .NET Framework class - the Close method on the server's end doesn't do the job it's suppose to be doing. Or there is an extra setting that must be done and I am missing it. BTW, Eric, setting the LingerTime didn't have any effect. Reading the docs, I guess that is more useful on the client (sender) side. > <stress>This has nothing to do with GC!</stress> You are right - I tried to garbage collect the object and there was no difference. >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. OK, I will try that too. It has become more of an academic exercise at this point. I am just curios to see how far can this be taken. Thanks for your suggestions. =================================== This list is hosted by DevelopMentorŽ http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
