Re: WebSocket options?

Israel Brewster <[email protected]>
writes:

... taking the last comment first ...

> (...)                                                     I spent today 
> re-implementing the web socket portions of the code in tornado, which 
> handles web sockets natively. So far, it just works - reliably, both ways, 
> with about half the code I had to write to get ws4py working semi-reliably. 
> So I'm abandoning ws4py. Thanks for trying though - I do appreciate your 
> time.

You sort of buried the lead, so this may be mostly moot, but in case
it's helpful to anyone, I'll add a few comments to the other questions...

... and now back to the top ...

> I'd agree with that. My issues arise from things like the socket still 
> being up, and the client receiving messages sent from the server, but the 
> server not getting messages sent from the client - including the close 
> message when the client terminates the socket. Or, of course, the 
> CLOSE_WAIT sockets I have mentioned. Neither of those fall under the 
> category of "nature of WebSockets in general" unless WebSockets simply 
> aren't ready for prime time.

I guess I see those as valid failure modes for long lived socket
connections under the right conditions.

Asymmetric routing (with failures/issues that can affect just one half
of a connectios) or NAT and NAT-like carrier translation boxes along the
way failing or timing out can cause such scenarios, for example.  And if
you're not getting messages from the client, whatever is blocking that
could certainly also block the socket FIN (or RST) packet as well.

By "nature of WebSockets in general" I was more referring to long lived
raw socket-like connections, which become subject to a variety of
failure modes you won't typically see with the much shorter lived HTTP
connection cycle.

With that said, if this was occurring on a LAN test environment, or you
kept everything else the same environmentally and you're not seeing the
issues with your Tornado-based system, then there could certainly have
been something else going on in the code.

If Tornado works better for your environment and needs, were I in your
shoes I'd probably switch as well.

> What OS are you running on? Version of CherryPy/ws4py/Python? What sort of 
> load? I've found better success running under Mac OS than under CentOS 6, 
> so apparently the operating system at least makes a difference.

For what I've currently got in production with WebSockets, it's Linux
(Ubuntu) on the server (CherryPy 3.2.4 fronted by nginx - 1.8.0 now but
1.6.x previously).  Production clients are Android (4.2.2 with Dolphin
browser) with demo/test clients as various browsers on various systems,
including ChromeOS.  Not a terribly high server load - maybe 10 or so
locations online simultaneously at peak - but they stay connected 7x24,
serving as digital signage at our locations.  I will say the issues I
worked on with respect to robustness apparent with just a few clients,
so not load-based.  They also only started showing up once I was in real
locations over the WAN.

To help keep things in line, I have an application level ping going in
both directions, failures of which case various retry/restart mechanisms
in both client and server.  I opted for application level rather than
just WebSocket ping/pong both to fully verify the stack on both sides
and also because I needed the client to recognize loss of contact with
the server and not just vice versa.  In the client code I use
reconnecting-websocket (https://github.com/joewalnes/reconnecting-websocket)
to help with the client side retry mechanism, and a new connection from the
same client causes the server to automatically prune the old connection,
since it might not yet have determined that the client has gone away.

For server-side pruning, I have a multi-step process, starting with
trying to force the client to restart, in case it can still hear me.
While it progresses to a close() on the WebSocket, that's not the last
stage since that still waits for a client to ack the close message which
may never happen.  So shortly thereafter, I explicitly terminate() the
WebSocket, and remove it from the manager object socket list.  At that
point I'm dependent on the client timing out and restarting on its own.

My server side process is very long lived, and does not accumulate any
backlog of hung or partially closed client connections.

To be honest, my biggest problem with the current architecture is the
client - the Android devices like to disable the wireless if they have
enough issues over a short span of time, thinking that they're saving
batteries, which is a bit frustrating.  The active signage code then
runs unattached, but I lose the ability to control/update pending a
restart.

-- David

-- 
You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cherrypy-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To post to this group, send email to cherrypy-users-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
Visit this group at http://groups.google.com/group/cherrypy-users.
For more options, visit https://groups.google.com/d/optout.