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

  • From: Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Wed, 19 Nov 2014 23:18:02 -0500

Hello team,

This sounds manageable and convenient for mapping app logic on top around a 
bunch of cleaner address connection strings. The implication here for websocket 
organization and writing server routing is big time.

My question may be outdated but permit me to ask while I am still trying to 
catch up and understand what's going on around here. 

What sort of I/O model, blocking or async (I would imagine implementing select 
and poll) presents the lowest average cost for binding communication between 
the tcpmux daemon and its corresponding recv function in nanomsg? 

Would the tcpmux daemon issue some sort of signal or call to nn_recv?

Sent from my iPhone

> On Nov 19, 2014, at 10:50 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> 
> -----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