Autobahn connection timeouts

[Theron Luhn]

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?

[Theron Luhn]

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 :)

— Theron

--
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.

[Tobias Oberstein]

Am 29.12.2013 06:13, schrieb Theron Luhn:
> 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 :)

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

>
>
> � 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%2Bunsu...@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

[Greg Fausak]

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</a>")

         }

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