[nanomsg] Re: WebSocket transport
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 16 Nov 2014 04:29:07 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15/11/14 22:22, Paul Colomiets wrote:
> Well, I don't believe it's good idea to make such ad-hoc things in
> one transport. For example it does solve the problem when single
> process want's to listen single port, but doesn't solve when there
> are multiple processes. So this case should be solved by one of
> the following:
>
> 1. Generic tunelling implementation. Where multiple nanomsg
> sockets are tunelled through single, probably PAIR socket. It's
> useful not only for port sharing, but for compression, encryption,
> etc. And not only for websocket transport.
>
> 2. A gateway approach a/k/a zerogw or mongrel2. The process that
> accepts connections, authenticates, does DoS protection, and
> tunnels messages to nanomsg network.
I would like to suggest to postpone this discussion. We have existing
ws transport to get into shape quickly and port sharing is not part of
that. It's rather a long-term goal.
Now, to violate what I just said, here's my view of how port sharing
(whether via WebSockets, TCPMUX or whatever) should look like in the
ideal case:
First, let's imagine that SP is implemented on the kernel level. It's
not a necessary assumption, but makes thinking about port sharing easier.
Furthermore, let's assume we have a fixed port allocated for the
multiplexer service. With TCPMUX, there's port 1. With WebSockets we
would have to register one with IANA, say port 12345.
Now, as the OS starts, the kernel starts listening on the port. That
way the multiplexer is available at all times.
User process binds to SP endpoint "ws://my-url". Kernel remembers
which socket is bound to which URL.
When there's a new incoming connection on port 12345, kernel checks
the URL and looks whether there is a socket listening on that URL. If
not so, it aborts the connection.
Otherwise, it passes the new connection to the user.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJUaBoDAAoJENTpVjxCNN9YUM4IAIqW59kAdlfYRjSHYS4txUmJ
AGB2luLKGrNipNiHx8SQspLXQlYaeX/r9hpSx2lphqPURvcgTzBGyjcHPhQ7eqYH
vTtvjv4jGremohvv5Zp2clXN16WlL3QBi5hSQ/bE8c55a1uamuaG65UoyVDCTiOv
N/OPNhbZDwWrbtGuglCFjOfzasgKPuArLpQy9w3wvYj3sgtorbNO1tUaqGMfsm01
LCBLoFd4Gimba8+IgoAcpGG5DlnOytMFsMSUQ93wl61sEr/yXVyIh4obe0ZFnsSp
5E/FWC4ElBfVBvzEoIn5lFqbCIxS0c/8Ugu/NX8sh/OrMO6RyOimTHjEtmVIeiU=
=tmB6
-----END PGP SIGNATURE-----
Other related posts:
