Re: Re: WebSocket options?

My apologies. Maybe I missed something, but I thought your messages 
basically said you don't really support ws4py much, so it would be a good 
idea to try something else. So that's what I did. I guess I could have 
responded with an acknowledgement of that, but I didn't really think of 
anything else that needed said. 

What it boils down to for me is that I need this product for a 
mission-critical application, so I can't be using software that doesn't 
have support behind it - especially if it isn't working, which ws4py hasn't 
been for me. With regards to tornado not implementing some aspects of the 
specification properly, that's news to me - thanks for the information. 
Maybe I'll continue looking. Although I did note in their release notes 
that they dropped support for some older versions of the specification with 
version 4 - maybe that is a fix for what you are referring to? All I know 
at this point is that tornado (so far - I only just implemented it 
yesterday) has provided reliable two-way communication over web sockets. 
With ws4py, I couldn't get two-way communication at all when deployed on 
linux - as I mentioned in my other thread you responded to.

Again, my apologies, and I truly hope I didn't offend.

------------
Israel Brewster


On Thursday, November 5, 2015 at 9:38:32 PM UTC-9, Sylvain Hellegouarch 
wrote:
>
> Hi Israel,
>
> I'm happy you've found happiness with Tornado (though last time I checked, 
> it didn't implement some aspects of the specification properly, so be 
> careful). 
> It's a bit sad you've managed to not answer any single of my messages but 
> fair enough.
> That's open source for you I suppose.
>
> Good luck :)
>
>
> 2015-11-06 2:36 GMT+01:00 Israel Brewster <[email protected] 
> <javascript:>>:
>
>>
>>
>> On Thursday, November 5, 2015 at 2:42:37 PM UTC-9, David wrote:
>>>
>>> Israel Brewster <[email protected]> 
>>> writes: 
>>>
>>> > The cpstats one is the only one I have posted as an "issue", since it 
>>> is 
>>> > the only one I have been able to track down. You may be right that it 
>>> isn't 
>>> > directly related to ws4py, but the fact remains that I can use 
>>> cpstats, or 
>>> > I can use ws4py, but not both - ws4py dies with cpstats enabled. 
>>> Nothing 
>>> > else does that I can see. That particular issue I posted on the issues 
>>> > list, this list, the ws4py list, and the general python mailing list - 
>>> and 
>>> > got no responses to any of them. 
>>>
>>> I definitely use ws4py in production and haven't had any notable issues. 
>>> I did need to expend some energy to ensure that handling lost and/or 
>>> disconnected sessions was robust, but nothing that I felt was an issue 
>>> with ws4py, just the nature of WebSockets in general (or rather to be 
>>> fair, any long-lived socket approach). 
>>>
>>
>> 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.
>>
>> 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.
>>  
>>
>>>
>>> I have no experience trying to mix with cpstats, but is there actually 
>>> use for cpstats on URLs on which you are using WebSockets - I wouldn't 
>>> think it would make much sense. 
>>>
>>> So what happens if you just ensure you don't have any URL where you 
>>> overlap both tools?  I'd think the only URL that needed the WS tool (and 
>>> not the cpstats tool) would be the one where you handle the transition 
>>> to the WebSocket.
>>>
>>
>> Admittedly, I just enabled cpstats on the root URL. I didn't try 
>> explicitly disabling it on the  web socket url's - that could potentially 
>> fix the problem.
>>
>> All that said, as you can see in the previous reply to this thread the 
>> author of ws4py admits that it was just a learning project, and not a top 
>> priority. As this is a mission-critical piece of software for the company, 
>> and I can't be relying on software that may be abandoned, 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.
>>
>>
>>> -- 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-user...-/[email protected] <javascript:>.
>> To post to this group, send email to cherryp...-/[email protected] 
>> <javascript:>.
>> Visit this group at http://groups.google.com/group/cherrypy-users.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> - Sylvain
> http://www.defuze.org
> http://twitter.com/lawouach
>

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