[nanomsg] Re: WebSocket transport
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 15 Nov 2014 22:42:55 -0800
> On Nov 15, 2014, at 7:48 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15/11/14 23:24, Garrett D'Amore wrote:
>
>> Well, I’m assuming that you need to use either different TCP port
>> numbers (or addresses), or use a two tier hand off, if you want to
>> work with separate processes. (Imagine a gateway process that
>> does the accept, a little bit of logic, and then forks the actual
>> actual application, choosing to exec() the appropriate app based on
>> the URI Path element.
>
> I was rather thinking of in the terms of the gateway sending the file
> descriptors to applications via AF_UNIX and SCM_RIGHTS.
That’s an equally valid approach, I think. :-) Indeed, I had similar thoughts
as well.
There are lots of way to handoff from a gateway process to some other nanomsg
service; I don’t necessarily think that this handoff will occur in the
libnanomsg API — or at least not in what we have today; it would use some kind
of new API or a totally separate implementation, I think.
In the meantime, the critical things to think about:
1.) What do service addresses look like… URIs path components work fine for me,
but we should have a spec for this if we are going to have it mean anything.
And even if not, we should say so.
2.) I remain opposed to the idea that we would encode string protocol names in
the websocket handshake — as much as possible the transport layer should have
no knowledge of the actual protocols. Keep the layer separations clean.
3.) As much as possible, once the connection is established, I think websockets
should look and act like established TCP streams from the perspective of the
protocol. I’d use the same framing and early negotiation (including
negotiation of the SP protocol and version) using the same binary packets.
- Garrett
>
> Martin
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJUaB55AAoJENTpVjxCNN9YslcH/0PtqV5WhWnbwLzsxoH7rHZd
> Ee3rfSqSjxRRtev5IXqhwTxBoerp6OztMkQQvYNZSZ1WQYR89YdKnueAYXC3NeCd
> Ea/q2GDhu8en1R6dbCz1Gi8/W/XpdiZ9glj7zLbucEtwavrkFHi6NmVStlYvvmxb
> DtoJW41z67rt+aN6yq+tPA7N3MrQmt5S6U9cwR56T+gro2sdJRZMcXR16PoHx47j
> GeBhCEahaMKHBVc4/u68+HxKkkNuDAEVDphw0uGVhNeTOY89pA4rXTodlBccE6BN
> 2Cyx+iBAqctQR8g39adrBy8/edmpfEmr1NsoC69BHzEk+NH5WX+WcNUWTDSJ7Iw=
> =kKUj
> -----END PGP SIGNATURE-----
>
Other related posts:
