[nanomsg] Re: WebSocket Transport design considerations
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Fri, 10 Oct 2014 09:02:50 -0400
There is an rfc for tcp+tls and mangos conforms to that protocol. I had started
enhancing libnanomsg for this as well but got sidetracked and didn't get far.
I would be happy to add websocket support to mangos as well. It should only
take a couple of hours. Go makes this very easy. :-)
Sent from my iPhone
> On Oct 10, 2014, at 4:28 AM, Paul Colomiets <paul@xxxxxxxxxxxxxx> wrote:
>
> Hi Jack,
>
>> On Fri, Oct 10, 2014 at 7:38 AM, Jack Dunaway <jack@xxxxxxxxxxxxxxxx> wrote:
>> I have begun investigating development of a WebSocket transport for nanomsg,
>> and I'm curious what design/implementation/brainpower others have put into
>> this already.
>>
>> The first stage "hack" in this investigation has been retrofitting the
>> existing TCP transport
>> (https://github.com/nanomsg/nanomsg/tree/master/src/transports/tcp) to
>> dispatch different handshake and send/recv handlers based on transport
>> scheme.
>>
>> Based on a day's worth of hacking, here are a few early-stage design
>> considerations:
>>
>> 1a) It feels heavy-handed to copy-and-paste the entire TCP transport
>> wholesale, just to change a few key areas where WebSockets differ (e.g., on
>> the surface, only STCP needs non-trivial modification). On the other hand,
>> the IPC transport very closely resembles TCP, so perhaps there's merit in
>> this duplication? That said, does it make more sense to duplicate the TCP
>> protocol as a starting point for the WS protocol, or to extend the existinga
>> TCP?
>
>
> Probably with current codebase you just have to copy. In fact IPC
> (unix sockets), transport is even more similar to TCP, but they don't
> share codebase. I think it's reasonable trade off.
>
>> 2) There exist several WebSocket protocol parsing libraries in C; however,
>> I'm not readily finding a sweet spot of License + Quality + RFC 6455
>> coverage. Ideas?
>
> I think it's easy enough to write your own. You can use autobahn as a
> test suite.
>
>> 3) Since the WebSocket protocol does not have a fixed-width header like the
>> nanomsg TCP wire-level protocol
>> (https://github.com/nanomsg/nanomsg/blob/master/rfc/sp-tcp-mapping-01.txt#L68),
>> this presents a fundamental new challenge buffering and parsing an incoming
>> stream. Thoughts?
>
> I don't think it's really complex stuff.
>
>> 4) For the ws:// protocol, how should a client negotiate scalability
>> protocol? Via parameters on the URI (e.g., ws://127.0.0.1:9876/?sp=NN_SUB)?
>> And, what shall be the value of Sec-WebSocket-Protocol?
>
> I'd say "Sec-WebSocket-Protocol: x-nanomsg-sub"
>
>> 5) Does it make sense to attack this problem of nanomsg<->WebSockets as a
>> specific application use-case, or as generally desirable transport
>> considered for inclusion into the core nanomsg library?
>
> Don't make a transport if you need websockets for specific application
> usage. Make a "gateway" -- a separate process which does translation,
> using any available http/websocket library.
>
>> 6) wss:// ... ?
>
> Yes, sure. Use libressl :). If you will be doing it, consider also
> looking at tcp+ssl implementation (latter should probably be
> compatible to mangos).
>
>
>
> --
> Paul
>
Other related posts:
