Re: WebSocket options?

On Saturday, November 7, 2015 at 11:49:51 AM UTC-9, David wrote:
>
> Israel Brewster <[email protected] <javascript:>> 
> 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... 
>

True, but to be fair the whole subject of this thread was looking for 
alternatives to ws4py/CherryPy, not trying to fix the issues I have been 
having. The threads I've posted looking for solutions 
(https://groups.google.com/forum/#!topic/cherrypy-users/2mKFdPJR9P4, https://groups.google.com/forum/#!topic/ws4py/RASY6WEzN_o, https://groups.google.com/forum/#!topic/ws4py/cmeZHKd8ezg) 
have gotten no responses other than the developer commenting on how they 
aren't going to be supporting the software. Which I COMPLETELY understand, 
BTW.
 

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

So likely something in my network setup rather than ws4py or CherryPy. 
Makes sense, although we'll see if the same issues arise with a separate 
process.
 

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

All of which are the case. I think I was probably even on the same switch 
as the server when I was doing some of the testing, and definitely on the 
same vlan in the LAN. The tornado based system hasn't gone live yet, so 
we'll see what happens there when that gets loaded.
 

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

Thanks again for the feedback, and spending your time on this. I'm sorry if 
I was a pain.
--------
Israel Brewster. 

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