[Bug 18524] Re: gaim hangs due to gnutls, switch to nss

[Eric Lee]

I am experiencing the bug as described by Kevin with Wildfire. I have
found that waiting about 10-20 minutes will bring back Gaim after such a
freeze (I'm guessing the operating system detected that the socket was
idle and dropped it, or something along those lines). At the bottom
there is a patch for Gaim that sets the socket timeout for closing the
connection to 3 seconds. I am using Gaim 1.5.0 (latest update for
Dapper) with Wildfire 3.0.0.

Here's a Debian bug filed about the same issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375317

Here's the research I have done on this issue:
The SSL connection close in Wildfire (source for version 3.0.0) happens at org.jivesoftware.wildfire.net.TLSWrapper.java:188. It performs SSLEngine.closeOutBound()

I also found this:
"To close the connection the user must first inform the SSLEngine that there is no more application data to be sent and, therefore, the session should be terminated. This is done by calling SSLEngine.closeOutbound(). After this, a call to wrap() will generate a close message that must be sent to the other peer. A well-behaved program should wait for the answer to this message, but the SSL/TLS specification says that it is acceptable to close the socket after sending the initial close message. And, typically, this is the easiest solution. After being closed, an SSLEngine cannot be reused."

The above is from:
http://www.onjava.com/pub/a/onjava/2004/11/03/ssl-nio.html

To me it sounds like Gaim is demanding that the close message be
received. I don't know any details about the specification, but if it is
optional then Gaim should not freeze the entire application while
waiting for the message.

-- 
gaim hangs due to gnutls, switch to nss
https://launchpad.net/bugs/18524