[nanomsg] Port sharing, tcpmux, web-related roadmap et c.

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg <nanomsg@xxxxxxxxxxxxx>
  • Date: Thu, 20 Nov 2014 04:50:29 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

There have been many discussions over the years and quite a few
discussions lately about port sharing (many nanomsg sockets sharing
the same TCP port) and dynamic port allocation -- which, as I argued,
is needed only because the namespace of TCP ports is heavily
constrained (16 bits) and thus preventing name clashes is a real problem.

To address the problem I've implemented "tcpmux" transport. (It's only
a preview for now and can be found on tcpmux branch of the official repo.)

tcpmux transport is similar to tcp transport except that you can
specify a service name in addition to tcp port:

nn_bind (s, "tcpmux://*:5555/myservice");
nn_connect (s, "tcpmux://127.0.0.1:5555/myservice");

There are no prerequisites for _connecting_ to a tcpmux endpoint. As
for _binding_ to a tcpmux endpoint, you have to have tcpmux daemon
running on the box. You can start the daemon like this:

tcpmuxd 5555

Technically, tcpmux is implemented according to RFC 1078
specification. tcpmux daemon hands over the incoming connections to
the applications via AF_UNIX/SCM_RIGHTS mechanism.

Some random comments:

1. Default tcpmux port, according to the RFC, is 1. Which is a problem
as root privileges are needed to use that port. Because of that, the
current solution has no default port. However, if we had a default
port, connection strings would look much nicer:

nn_bind (s, "tcpmux://myservice");
nn_connect (s, "tcpmux://gateway.example.org/myservice");

2. A similar approach can be used for multiplexing WebSocket
connections. In such implementation, URL can be used as a service
name. Interestingly, the connecting side (client) doesn't even have to
be aware that there is a multiplexer on the other side:

nn_bind (s, "wsmux://myservice");
nn_connect (s, "ws://www.example.org/myservice");

Btw, the above looks like a reasonable first step towards integration
of nanomsg with the web. Imagine following set of features:

a.) Simple JavaScript client.
b.) WebSocket and WebSocket/SSL transports.
c.) Multiplexer, so that no TCP ports except 80 and 443 have to be used.
d.) Possible integration with web servers so that web pages and
nanomsg services can share the same namespace (?)

Thoughts? Comments? Ideas?

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJUbWT8AAoJENTpVjxCNN9Y1LcH/1M3CMujmpr5aIKTbY8fJ1vL
kesa2CXRG5RrMRMOJLLwlA3+YjgeZsH6RCCON3wlsDOT2Ld0NDxrnT6Vp8YyInoV
E4TPU+804zU0dOSu7b5rYX9dGm/APWxaDdvH/iPnOpD4E3Rqk9AFYBrZrFXzl87s
UKgbu75rLBWg0Anioy7Re2pJZKxON7irCBHQNYaJXg9OFow/rHbG+uVxCAZvfGV0
Q2OOQLEmdhQJFcMtjz+WsVk7fwUpWF7xBgePzsCD4kHeokrJU5hNR3iZra8ZOBdf
IEagk047cKJtR4UAuH0h2qaIShDsUF6NOFlyq9ErJbDIYdg/IZar0tWffIMW9h4=
=D4mi
-----END PGP SIGNATURE-----

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 11-2014