Re: Re: WebSocket options?

Hi guys,

just to report some positive news ... we are using ws4py in a
productive environment, it works like a charm.

And I found it extremely simple to use, some 5 to 10 lines of Python
code, what else do we want?

ciao ciao

Ralph

On 07.11.15 00:08, [email protected]
wrote:

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 [email protected].

To post to this group, send email to cherryp...-/[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-/[email protected] .

To post to this group, send email to [email protected] .

Visit this group at http://groups.google.com/group/cherrypy-users .

For more options, visit https://groups.google.com/d/optout .

--

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-/[email protected] .

To post to this group, send email to cherrypy-users-/[email protected] .

Visit this group at http://groups.google.com/group/cherrypy-users .

For more options, visit https://groups.google.com/d/optout .