On Sep 18, 2013, at 1:59 PM, Bob Novas wrote:

I’ve got a question on how to explicitly disconnect a connection from the client side so that the server side knows that the connection has been disconnected. I’d be happy if this worked even with no guarantees, i.e., only when the client and server were in fact well-connected. It’s just an optimization to allow the server to cleanup.

I’ve got an HTTP client that uses HTTPConnectionPool to get an Agent, gets a Request from the Agent, and sends the Request to a WebServer on a linux box.

On a Mac client, if I call closeCachedConnections() on the HTTPConnectionPool, the client immediately sends FIN on the port with the Request outstanding, the server delivers a callback registered on the Request via NotifyFinish() and the server knows the client has disconnected.

Sounds right...

On a Windows client, if I do the same, same code, the client waits until the outstanding Request finishes and then sends FIN. Nothing happens at the server – there’s no Request outstanding on which to deliver a callback, twisted.internet.tcp.Port.connectionLost() doesn’t get called, nada.

So, tcp.Port.connectionLost is only called when the *listening port* is shut down, i.e. when the server stops listening entirely. What you should be looking for is connectionLost on your particular Protocol.

Am I missing something? Is there a way to send a FIN on a connection on which there is an outstanding Request on Windows?

Twisted should behave the same way on all platforms, at least, if you're using portable APIs. Usually, when the TCP stack completely goes out to lunch on Windows, it's due to some bizarre antivirus software that's just buggy. For a while, possibly still today, Twisted just completely dies with certain versions of AVG installed, because they completely break the expected behavior of certain socket APIs. Have you tried with multiple Windows clients yet? Different versions of Windows? Different software installed? -glyph