Awesome, in my actual code I already implemented something to see if I was "done" with the socket conversation. I was just getting really worried about the "non-clean" messages. Your explanation makes perfect sense. Thanks for the help.<div>
<br></div><div>Dan<br><br><div class="gmail_quote">On Sun, Jan 17, 2010 at 11:55 PM, Glyph Lefkowitz <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Jan 17, 2010, at 10:45 PM, Daniel Griffin wrote:<br>
<br>
> Here are two tiny apps. They run perfectly on OSX and error like this on windows:<br>
><br>
> Log conenction [Failure instance: Traceback (failure with no frames): <class 't<br>
> wisted.internet.error.ConnectionLost' Connection to the other side was lost in<br>
> a non-clean fashion.<br>
> ] Log conenction [Failure instance: Traceback (failure with no frames): <class<br>
> 'twisted.internet.error.ConnectionLost' Connection to the other side was lost<br>
> in a non-clean fashion.<br>
<br>
</div>Ah. This is very simple, and luckily has nothing to do with threads.<br>
<br>
The simplest explanation is that these errors are showing up because you are printing them out :). If you stop printing them out, they won't show up.<br>
<br>
More specifically: You generally shouldn't worry about "clean" vs. "non-clean" connection shutdown. There are lots of things that can cause "clean" shutdowns to still lose data, and there are many cases where a "non-clean" shutdown is actually fine. Your application protocol should be framing messages such that you can tell which ones have been responded to.<br>
<br>
That said, what's going on here is pretty simple. A "clean" shutdown is, broadly speaking, when both ends of the TCP connection agree on where the stream of bytes begins and ends. I send you some data, you read all of it, I shut down the connection, you shut down the connection. If I send you some data, and you *don't* read all of it, then I shut the connection down, the result will be a "non-clean" shutdown, because there is still data outstanding when the connection dies.<br>
<br>
In this case, you are calling recv(5) in your server, but your client is writing "RESPOND" to its transport. As you can see,<br>
<br>
>>> len("RESPOND")<br>
7<br>
<br>
"RESPOND" is more than 5 bytes.<br>
<br>
If you were using Twisted for your server, this wouldn't happen because Twisted always reads all the bytes that are available and delivers them to dataReceived.<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</div></div></blockquote></div><br></div>