On Jul 29, 2013, at 12:48 PM, George Pauly george@ringdevelopment.com wrote:

Hi Brian,

On Mon, 2013-07-29 at 14:01 -0400, D Brian Kimmel wrote:

...

Howdy,

I have a large home automation project that uses twisted. I am adding a web interface and need athena for COMET activity.

I have been having a very hard time finding any current documentation to help me get the athena part working. I am looking for brains to pick on getting this portion working bi- directionally.

websockets is the way to go. Very simple on both ends. You may still need to import this separately into your code, however it seems pretty well developed. Except docs. However, docs are hardly needed, just follow an example.

Athena is more portable than websockets, and besides, does a lot more. You could replace the implementation of Athena's message passing with websockets for better performance on browsers that support it, and the interface to the user would not visibly change.

So I would say stick with Nevow and maybe send a patch to it to add websocket support if you need it.

(Contingent, of course, upon you finding someone to help you with it...)

Some docs are available here: http://divmod.readthedocs.org/en/latest/products/nevow/index.html. Although they're incomplete (a partial snapshot of a wiki lost to a hardware failure), they might be able to get you started.

Good luck,

-glyph

On Jul 29, 2013, at 3:10 PM, Werner Thie werner@thieprojects.ch wrote:

I've written a few Nevow/Athena based game servers in the last years, and I'm still convinced that I have chosen the right technology for the problems at hand. Time given, I might tackle the coding to have the underlying transport to be switched to websockets when available as Glyph suggested, but currently I see no performance issues and the servers are running with uptimes now measured in years.

To be honest, the main reason to add websocket support is not so much that there is a significant performance problem that needs to be addressed, but rather that people are going to show up _expecting_ that there's a significant performance problems because they've heard on some JavaScript forum that websockets are fast :). If Nevow can just tick that box on the feature list, there's that much less to argue about.

Glad that Nevow has been working well for you, though :)

-glyph

On Jul 29, 2013, at 5:00 PM, Tristan Seligmann mithrandi@mithrandi.net wrote:

On Tue, Jul 30, 2013 at 12:31 AM, Glyph glyph@twistedmatrix.com wrote:

On Jul 29, 2013, at 3:10 PM, Werner Thie werner@thieprojects.ch wrote:

...

I've written a few Nevow/Athena based game servers in the last years, and I'm still convinced that I have chosen the right technology for the problems at hand. Time given, I might tackle the coding to have the underlying transport to be switched to websockets when available as Glyph suggested, but currently I see no performance issues and the servers are running with uptimes now measured in years.

To be honest, the main reason to add websocket support is not so much that there is a significant performance problem that needs to be addressed, but rather that people are going to show up _expecting_ that there's a significant performance problems because they've heard on some JavaScript forum that websockets are fast :). If Nevow can just tick that box on the feature list, there's that much less to argue about.

I'd like to add that I'm aware of at least one significant performance problem[1] in Athena (not sure if there's a bug report lying around for it anymore, although I think there was one in Trac-that-was), but it's to do with the reliable delivery transport that Athena runs on top of long polling (which I believe would still be required on top of websockets), rather than the long polling / HTTP itself. Long polling in general is pretty reliable, the main problem is with proxy servers that time the connection out faster than Athena recycles it, but this value is configurable so the problem is easily worked around.

[1] When sending several messages "at once" with Athena under some specific set of circumstances (I'm not sure exactly what they are, but the behaviour is repeatable), the one side will ACK the first message before processing the second message, leading to the other side retransmitting the remaining messages even though they were not lost. This shows up as multiple "Athena transport duplicate message, discarding: ..." log messages, and has the result of increasing bandwidth usage / latency; depending on the number / size of the retransmitted messages, the impact may be negligible or noticeable.

This does sound like a real bug :). My point is that it's not one that would necessarily be addressed *just* by switching to websockets...

-g

ISTR my reason for not picking Athena was that the cross-domain story isn't great. You can do cross-domain stuff with CNAME hacks, except then you don't get TLS, unless Twisted suddenly does SNI or you have a cert with ten gazillion alternative CNs.

WebSockets don't have the above problem, and IIUC neither does SockJS.

I realize this is an issue for few people :)

cheers lvh

On Tue, Jul 30, 2013 at 3:43 PM, exarkun@twistedmatrix.com wrote:

On 12:01 pm, _@lvh.io wrote:

...

ISTR my reason for not picking Athena was that the cross-domain story isn't great. You can do cross-domain stuff with CNAME hacks, except then you don't get TLS, unless Twisted suddenly does SNI or you have a cert with ten gazillion alternative CNs.

There's no problem doing SNI with Twisted.

Right, you can do SNI (figuring out how is kind of non-trivial, presumably less so if you're the PyOpenSSL maintainer :)) and Twisted doesn't really help nor get in the way, sorry.

I think my actual issue (this was a while ago) with SNI wasn't the server side, it was terrible clients that don't understand SNI, particularly IE on WinXP.

Anyway, my point is that the cases where you Athena can't cut it are small, and it's probably good enough, which I guess has been made before in this thread ;)

cheers lvh