[nanomsg] Re: RFC links
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 12 Aug 2013 10:17:22 -0700
On Monday, August 12, 2013 10:07:41 AM Martin Sustrik wrote:
<snip>
> API-wise it you would have 2 options:
>
> nn_connect (s, "tcp://23.45.67.89:5555");
>
> or
>
> nn_connect (s, "tcpmux://23.45.67.89:myservice");
>
>
> That being said, there's one more thing to consider. Namely, SP's
> notion of services is much finer grained that classic TCP services. For
> example, stock trading application may use service A for receiving
> market data, service B for posting orders to an exchange, service C for
> yet something else. At some point you want to add heartbeats to the
> application. You define new service D to carry the heartbeats. Is
> network admin really supposed to care about this new heartbeat service?
> It's almost an implementation detail.
You're trying to solve three things at once, and I think you're trying to
solve them at the wrong (TCP) level.
> So, the question is: Can we draw a line between new service as "new
> functionality, completely independent from anything running on the
> machine so far" and new service as "new communication channel for an
> existing application"?
The first thing you're trying to solve is "I have a service with multiple
components, and want the components to be on the same port." This is something
I think should be done at the SP level, by including a component identifier in
the SP protocol header/handshake.
The second is "I want the components to be identified by string names, not
port numbers." The above applies, just make the component identifier a string.
The third is "I want to identify the *service itself* as a string, too." I
think this should be solved by DNS SRV.
As far as solving it in the SP layer, there's a perfect way to do that -
XFOO/XBAR devices are *already* designed to be transparent. Have it so that
when nn_bind is called with NN_MULTI, and the nn_socket has a
topology/component identifier string set (nn_setsockopt?), then a multiplexer
is spawned (on first bind) or negotiated with (for the others). The
multiplexer instantiates the appropriate XFOO/XBAR device, and passes messages
on appropriately.
That way, you still have one port per service, you have the components of that
service all there, you don't need to do (non-portable) socket handoffs, you
aren't using a global namespace (IANA port 1) for something that's really
service-namespaced (component names - if you have multiple *actual* services
using the same nanomsg-based protocol, tcpmux gets ugly because helloooo
namespace collisions), you aren't letting arbitrary TCP traffic pass through
(which is something that could give any security-conscious admin hives)...
I think that's a much cleaner solution; it even has the side benefit that it
works for WHATEVER transports SP may get in the future. You may have only
defined the TCP binding so far, but when that changes you don't want to have
built a lot of TCP-assumptions into other layers.
Other related posts:
