<div dir="ltr">Ah, I never tried abortConnection, but I'm doing something similar - I just call loseConnection() and that does the trick. And yes, I believe that the TCP connection does stay alive because I was watching closeSocket() and it was never called.<div>
<br></div><div style>I wish I could be more helpful with regard to code samples to reproduce this - but right now my stuff is a mess.</div><div style><br></div><div style>We're using the wokkel library, calling stopService() when we want everything to be cleaned up. They override that function, but I believe they're doing everything correctly. Basically, they're just calling connection.disconnect() - and eventually the shutdownTLS() gets invoked.</div>
<div style><br></div><div style>Maybe most people just never care about having to clean up their connections during a single session? As for a fix - maybe it's not necessary to do the test for</div><div style>if shutdownSuccess in _shutdownTLS() ?</div>
<div style><br></div><div style>According to the ssl spec, it's not absolutely necessary to wait for the server to return the close handshake.</div><div style><br></div><div style>That being said, that seems lousy - and it really seems like something else must be going on.</div>
<div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 28, 2013 at 4:36 PM, Glyph <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com" target="_blank">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="HOEnZb"><div class="h5"><br>
On Mar 28, 2013, at 9:24 AM, Michael Williamson <<a href="mailto:williamson.michaelr@gmail.com">williamson.michaelr@gmail.com</a>> wrote:<br>
<br>
> Hi, I'm having an issue where a tls connection never seems to shutdown properly, and as a result, all the associated cleanup never happens.<br>
><br>
> Basically we're trying to implement a jabber client and allow the user to sign out and then re-sign back in without completely quitting the program. When the user tries to sign back in, Twisted goes nuts because the original connection was never shutdown properly.<br>
><br>
> So, I traced through the code with the debugger and I came to the _shutdownTLS() function in tls.py. I believe that what's supposed to happen is that the first time through, the self._tlsConnection.shutdown() returns False because the shutdown is initiated. Then, when the 2nd part of the shutdown handshake comes back from the server, dataReceived is called, which calls shutdownTLS again, and then the cleanup can continue.<br>
><br>
> The problem is that after the initial call to shutdownTLS, I never see anymore data from the server. I'm not sure if it's a server issue (we're just connecting to the Google jabber servers) where they don't close down their SSL connections correctly, or if I'm just doing something silly. So anyway, I could solve this by overriding a bunch of stuff and ensuring that self.transport.loseConnection() gets called no matter what, even when the server doesn't respond with the second part of the close handshake, but I figured I'd ask here first.<br>
><br>
> So, any TLS experts out there? Thanks for any help or information - I really appreciate it,<br>
<br>
</div></div>Sadly I don't know enough about TLS specifics to tell you for sure.<br>
<br>
It sounds like you may have spotted a bug. More investigation is required though. Does .abortConnection() do what you expect? In your current problematic scenario, does the TCP connection to your peer stay alive?<br>
<br>
-glyph<br>
<br>
<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>
</blockquote></div><br></div>