| Newsgroups |
gmane.comp.python.cherrypy |
| Message-ID |
<[email protected]> |
That you couldn't get two-way communication is very strange. That worked
out of the box fox me.
Are you saying that the example doesn't work for you? Because if I remember
correctly, that was two way.
I would advise you to start an issue on the ws4py git hub, I can't see that
there is one about your problems with two-way communication.
Well web sockets, as a concept, are not only ready for prime time, they are
also really nothing really that new.
WRT to Tornado, there is no problem as long as you stay on Linux, but to
quote the documentation "Tornado will also run on Windows, although this
configuration is not officially supported and is recommended only for
development use."
I tried it for a while, but that aspect became a show stopper for me.
Also, it was harder to maintain an understandable structure for the
application.
It made everything not only more complicated to build, but especially to
deploy.
I would say that "robust" is a very popular but complicated word to throw
around, I don't know in what way either of these framework are more
"robust".
//Nicklas
On Friday, November 6, 2015 at 3:45:39 PM UTC+1, Israel Brewster wrote:
>
> 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]>:
>>
>>>
>>>
>>> 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...-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
>>> To post to this group, send email to cherryp...-/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.
>>>
>>
>>
>>
>> --
>> - 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.