Autobahn connection timeouts

#1

This is a problem I have encountered in previous Twisted servers I’ve written.

If a client disconnects uncleanly, Twisted won’t be aware of the disconnect and the connection will persist server side. After a while, hundreds of these unused connections can accumulate.

Does Autobahn handle this? Or will I need to use something like TimeoutFactory to prevent this?

0 Likes

#2

I overlooked something: As long as the server is sending data, a TCP timeout will occur after a while and the connection will be closed. And since the application I’m writing uses PubSub heavily, this shouldn’t be a problem.

But if the community doesn’t mind answering, though, I still am curious :slight_smile:

···

— Theron

On Sat, Dec 28, 2013 at 8:09 PM, Theron Luhn tjl...@gmail.com wrote:

This is a problem I have encountered in previous Twisted servers I’ve written.

If a client disconnects uncleanly, Twisted won’t be aware of the disconnect and the connection will persist server side. After a while, hundreds of these unused connections can accumulate.

Does Autobahn handle this? Or will I need to use something like TimeoutFactory to prevent this?

You received this message because you are subscribed to a topic in the Google Groups “Autobahn” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/autobahnws/2BrAT58kY2s/unsubscribe.

To unsubscribe from this group and all its topics, send an email to autobahnws+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

0 Likes

#3

I overlooked something: As long as the server is sending data, a TCP
timeout will occur after a while and the connection will be closed. And
since the application I'm writing uses PubSub heavily, this shouldn't be
a problem.

But if the community doesn't mind answering, though, I still am curious :slight_smile:

If a TCP client program is stopped, killed or the OS is shut down, the TCP networking stack within the OS will (normally) actively close the TCP connection, and your server will immediately recognize. The TCP closing involves sending IP packets to the server.

If you pull the plug or the networking wire on a TCP client, no active close is (obviously) being done. And this appears to your server as if the client was just inactive.

Hence, to have the server recognize the latter situation and differentiate it from mere inactivity, your server must send data.

On the TCP level, there is a retransmission timeout, and then multiple retransmission attempts, and it takes quite long until TCP gives up and reports the client as unreachable.

On the WebSocket level, you can do WebSocket pings. The WS peer must pong back. If that isn't received in a timely manner you can bail out. Moreso: the timeout is under your control.

/Tobias

···

Am 29.12.2013 06:13, schrieb Theron Luhn:

� Theron

On Sat, Dec 28, 2013 at 8:09 PM, Theron Luhn <tjl...@gmail.com > <mailto:tjl...@gmail.com>> wrote:

    This is a problem I have encountered in previous Twisted servers
    I've written.

    If a client disconnects uncleanly, Twisted won't be aware of the
    disconnect and the connection will persist server side. After a
    while, hundreds of these unused connections can accumulate.

    Does Autobahn handle this? Or will I need to use something like
    TimeoutFactory
    <http://twistedmatrix.com/documents/11.0.0/api/twisted.protocols.policies.TimeoutFactory.html>
    to prevent this?

    --
    You received this message because you are subscribed to a topic in
    the Google Groups "Autobahn" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/autobahnws/2BrAT58kY2s/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    autobahnws+...@googlegroups.com
    <mailto:autobahnws%2...@googlegroups.com>.
    For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

0 Likes

#4

I ran in to a disconnect issue with the authorization stuff. The tcp/ip half open sockets would stick around for the timeout period (an hour or two). This consumed resources and acted like a DoS attack. I experienced this when I first started with ssl on the web socket. I was using a self signed cert. When trying to connect the protocol would failed because I never authorized use of the self signed cert. The work around was to connect directly to the web socket server via the browser and allow the browser’s mechanics to opportunity to accept the self signed certificate.

This isn’t just a problem with Twisted, I’ve experienced this specific problem with other network programs.

A little off topic, but, I was thinking about putting an error catch block in the example code for ssl that puts up a link redirecting directly to the web socket if this sort of thing happens. But, that would be for version 1, I realise version 2 is what is being worked on now. I would think it would go in client.html in echo_tls directory, around:

window.onload = function() {

if (sock) {

} else

log(“Try clicking on <a href=”" + wsuri + “”> to authorize self signed cert")

}

I don’t know javascript too well, the log() wouldn’t be the right place, but, it might get the message across to the developer.

-g

···

On Saturday, December 28, 2013 9:09:46 PM UTC-5, Theron Luhn wrote:

This is a problem I have encountered in previous Twisted servers I’ve written.

If a client disconnects uncleanly, Twisted won’t be aware of the disconnect and the connection will persist server side. After a while, hundreds of these unused connections can accumulate.

Does Autobahn handle this? Or will I need to use something like TimeoutFactory to prevent this?

0 Likes