Re: [Erlyaws-list] Websocket API and review request

[Wes James <comptekki@gm...>]

Jan,

You may want to look at the cowboy or misultin implementation of
websockets.  I switched a small app I'm creating to misultin because
websockets was not complete enough in yaws.  I've had no trouble with
misultin on chrome 15.x right now.

Thanks for your updates!

-wes

On Thu, Nov 17, 2011 at 12:36 PM, Jan Bothma <jbothma@...> wrote:
> Hi,
>
> I've gotten pretty far with adding websocket support to Yaws 1.91.
>
> I think it's time to hear how people would like to use it, and get
> comment on my code.
>
> The old Websocket support was based on the hixie group's protocol. It
> sounds like the hybi group's protocol is getting close to finalisation
> and it's quite different from the old one. The old protocol support in
> yaws included a .yaws file as the endpoint requested by the JavaScript
> API, which calls a handshake function and then enters a server loop.
>

[Erlyaws-list] Websocket API and review request

[Jan Bothma <jbothma@gm...>]

Hi,

I've gotten pretty far with adding websocket support to Yaws 1.91.

I think it's time to hear how people would like to use it, and get
comment on my code.

The old Websocket support was based on the hixie group's protocol. It
sounds like the hybi group's protocol is getting close to finalisation
and it's quite different from the old one. The old protocol support in
yaws included a .yaws file as the endpoint requested by the JavaScript
API, which calls a handshake function and then enters a server loop.

I based my work on that, but changed things as necessary, and the
result is more like a bunch of handler functions called by the server
loop.

At the Erlang User Conference I saw that the Cowboy server lets
application developers register handler modules, whose handler
functions get called very much like a gen_server callback module.

I think it would be really nice to move the server loop into the yaws
websocket libraries and let application developers simply define a
callback module. A .yaws file at the endpoint could start the process
like it does now, with configuration options like what Origin header
should be enforced, if any, and name the callback module.

Does this sound like a nice way to program websocket endpoints?

Something I haven't added yet is configuration of the expected Origin
URL. For browser clients, this should be enforced to avoid attacks.
For non-browser clients where this is not relevant (currently for the
Autobahn test suite), this should not be enforced at all. Any comment
on that?

Another config option is the maximum sized message expected. I think
it can technically be something like 2GB, but I'm sure something will
crash before that. I run out of swap space before that. I think I
allow up to about 2GB and Autobahn tests up to about 16MB, but do
people agree that this should be a config option for the application
developer? What's a sane default, if any? The common use case for us
is less than 1kb of JSON.

I'd welcome comments on the code at
https://github.com/jbothma/yaws/tree/websocket_hy10. Note the work is
in the websocket_hy10 branch.

Autobahn test results for a recent version at
http://jbothma.co.uk/websocket/autobahn_yaws_b5d92/

The only up to date endpoint is the autobahn one. This means the test
web page doesn't work right now. From the autobahn endpoint you should
be able to create a working echo test web page if you wish. My
implementation supports Chromium 14 but it should work with anything
using Websocket 8. Since it doesn't know about Websocket 16 it will
just die or break or something. I don't think there are significant
changes needed to upgrade except adding negotiation. I haven't
considered SSL connections at any stage but they should not be too
difficult to add.

BTW the complexity in the handlers and the yaws_websocket module is
that WS messages can be fragmented over several frames, frames can be
fragmented into packets depending on buffers along the TCP connection,
and there's no guarantee that one packet contains only one frame. A
packet might contain the end of one frame and the beginning of the
next. I'm hoping refactoring can hide a lot of this from the user, but
the user will still have to deal with fragmented messages to some
extent. Messages may also be fragmented by intermediaries like proxies
along the way if they're aware of WebSocket. Suggestions here would be
VERY welcome :)

Regards,
JD