There's no documentation on what crypto.tls.Conn.WaitConnectionState is
actually supposed to do, so maybe this is intentional, but looking at the code,
it appears that if the handshake has already been made by time the caller
calls WaitConnectionState, then he will get an immediate ConnectionState
response, and then the channel will still get queued.
I would think the channel should only get added to waitQueue if the
handshake has not already been made, so that the record processor does not
try to write to the channel again later.
The text was updated successfully, but these errors were encountered:
Hi Matt :)
Sorry for the delay. I'll see if I can take a look at this today. In short: the TLS
package is rather incomplete. Mostly I need a week to flesh it out. You're welcome to
email me directly if you intend to use it in anger.