[zeromq-dev] RFC: "transport" vs. "endpoint" and orthogonal addressing

[Steven McCoy]

2010/1/27 Martin Lucina <mato at kotelna.sk>:
> It seems to me that there's no reason for having this distinction where
> it's not required. I'm not sure about PGM but at least for unicast TCP/UDP
> the syntax would be much nicer if it worked like this for both bind() and
> connect():
>
> transport://(interface-name | host-name | ip-address):port

The Rendezvous network parameter in OpenPGM takes to cover any method
of specifying an interface, ending up with quite complicated code.
You can use interface name, host IP address, network IP address, CIDR
block, host name, or network name.  The goal being to allow the
administrator to specify one parameter for a homogeneous network with
different interface names and addresses.

http://code.google.com/p/openpgm/wiki/OpenPgmConceptsTransport

You can also specify the multicast parameter as a DNS or NSS network
name where it is supported, this is an extension to TIBCOs evaluation.

The interface to creating an OpenPGM transport actually takes an
RFC3678 parameter, struct group_source_req, the Rendezvous network
parameter is provided as a convenience.

In contrast I think the goal of ZeroMQ is to provide a simple and
well-defined interface which is easy to test.  It's usually a good
idea to try to leave out host name lookups because they can be
expensive, time wise, and can fail in many different ways.  It's very
annoying as an administrator to specify a local name but have to wait
for a DNS lookup to timeout before the transport initiates.

-- 
Steve-o