[nanomsg] Fwd: Re: Re: RFC links

From: Martin Sustrik <sustrik@xxxxxxxxxx>
To: nanomsg <nanomsg@xxxxxxxxxxxxx>
Date: Sat, 10 Aug 2013 08:50:49 +0200


Hi Alex,

While they may be requesting "named services," they may not realize the
tradeoffs that are required to implement them - those basically come
down to either doing the SUNRPC thing and adding a roundtrip (and
dynamic ports, which suck; see portreserve for the kind of stuff people
have to do to prevent it from claiming ports that really do matter), or
doing the TCPMUX thing and sharing a port (which has its own drawbacks).
You will need to be explicit about that.


Dynamic ports are pain in the ass. First, you never know what they will
clash with, second, you have to distribute the port number to the peers
using some kind of service discovery which in turn makes everything more
complex etc.

ETSN, TCPMUX or similar is a way to go IMO.

I honestly think the 'right' solution is DNS SRV records, and using
Zeroconf for non-infrastructure situations.n


You are confusing two different problems here IMO:

The first are the addresses of physical endpoints: IP addresses, TCP
ports, TCPMUX service names etc. These are resolved directly by the
network stack proper, not DNS.

The second are logical addresses of services (i.e. names pointing to
functionality rather than location). These should definitely be resolved
using DNS.

This thread is related only to the former problem. The latter one should
be discussed separately.

Anyway, there's no need to clash with inetd. From the manpage:

"TCPMUX requests are only accepted when the multiplexor service itself
is enabled, above and beyond and specific TCPMUX-based servers"

That means you can have a tcpmux implementation listening on port 1
without colliding, as long as inetd's TCPMUX is turned off in the config
file.

Another option is to have a stub program that passes FDs to your TCPMUX
implementation, and is configured in inetd.conf to handle the
appropriate TCPMUX services (admittedly, this is using a slightly silly
level of indirection) - it takes the FD, and have it take the
servicename as argv[1]. Then it can handoff to your TCPMUX. That allows
interoperation with existing TCPMUX services (which I do believe to be
rare in the wild).

Additionally, systemd is doing inetd's job on a number of systems, and
does not handle TCPMUX.


That's sounds promising. Port 1 should be free on most systems then.

Btw, I've posted a question about status of TCPMUX at IETF discuss
mailing list. Let's see what people have to say about that.

Martin

[nanomsg] Fwd: Re: Re: RFC links

Other related posts: