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.
Dan
On Sun, Jan 17, 2010 at 11:55 PM, Glyph Lefkowitz
<gl...@twistedmatrix.com>wrote:
>
> On Jan 17, 2010, at 10:45 PM, Daniel Griffin wrote:
>
> > Here are two tiny apps. They run perfectly on OSX and error like this on
> windows:
> >
> > Log conenction [Failure instance: Traceback (failure with no frames):
> <class 't
> > wisted.internet.error.ConnectionLost' Connection to the other side was
> lost in
> > a non-clean fashion.
> > ] Log conenction [Failure instance: Traceback (failure with no frames):
> <class
> > 'twisted.internet.error.ConnectionLost' Connection to the other side was
> lost
> > in a non-clean fashion.
>
> Ah. This is very simple, and luckily has nothing to do with threads.
>
> 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.
>
> 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.
>
> 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.
>
> In this case, you are calling recv(5) in your server, but your client is
> writing "RESPOND" to its transport. As you can see,
>
> >>> len("RESPOND")
> 7
>
> "RESPOND" is more than 5 bytes.
>
> 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.
>
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
