On Thu, Jan 26, 2012 at 03:51:17PM +0000, Robert Kern wrote:
> On 1/26/12 3:07 PM, AJ Lewis wrote:
> > On Thu, Jan 26, 2012 at 03:57:37PM +0100, Martin Lucina wrote:
>
> >> This leaves us with something like this proposal:
> >>
> >> zmq_bind(foo, "tcp://XXXX:*"); // "tcp://*:*" if you want
> >> INADDR_ANY char endpoint [ZMQ_ENDPOINT_MAX]; zmq_getsockopt(foo,
> >> ZMQ_GET_ENDPOINT, endpoint, sizeof endpoint);
> >>
> >> => endpoint is filled as "tcp://XXXX:12345".
> >>
> >> zmq_bind(foo, "ipc://*"); char endpoint [ZMQ_ENDPOINT_MAX];
> >> zmq_getsockopt(foo, ZMQ_GET_ENDPOINT, endpoint, sizeof endpoint);
> >>
> >> => endpoint is filled as "ipc:///tmp/Xyz358hfA7".
> >>
> >> inproc:// semantics would be identical to ipc:// (w/o the /tmp/
> >> prefix obviously).
> >>
> >> The use of "*" seems fairly uncontroversial -- note that this means
> >> an ipc:// endpoint cannot therefore contain "*" which is an (albeit
> >> niche) backward-incompatible change.
> >
> > I think the "*" is fine, and it makes sense to me to extend it to
> > all endpoint types. I'm a bit concerned about having the full
> > ${transport}://${path/port} string passed back. That means that the
> > app needs to parse that string out to get what it needs, when what
> > it really wants is just the ${path/port} depending on the transport.
> > Is there a reason to include more than the part of the transport
> > string that was wildcarded?
>
> The immediate use case I can think of is to make an ad hoc channel for
> communicating with a particular client and communicating the new
> endpoint to the client via an already established channel. While that
> my code (and possibly the client) already "knows" the transport and
> the hostname and just needs to know the port, what it really wants to
> communicate is the endpoint that the client should connect to. If I
> just get the port number, then I still need to reconstruct the whole
> endpoint string in order to connect to the new bound socket. I think
> this is universal. Every time you bind a socket, you want something
> connect to it, and that something needs the full endpoint address in
> order to connect.
Hrm...what I was thinking of was the initial establishment of a
connection. For TCP for example, this could be via a portmapper or
zeroconf, in which case all you care about is the port number. I could
see the full string being useful in the pre-established connection case,
or for inproc, where the binding thread creates the worker threads and
simply passes the inproc string on.
I guess having that be the standard and either having a helper function
in zmq proper, or in the language bindings, to do the parsing out of the
wildcard part probably makes the most sense.
Regards,
--
AJ Lewis
Software Engineer
Quantum Corporation
Work: 651 688-4346
----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any
disclosure, copying, or further distribution of confidential information is not
permitted unless such privilege is explicitly granted in writing by Quantum.
Quantum reserves the right to have electronic communications, including email
and attachments, sent across its networks filtered through anti virus and spam
software programs and retain such messages in order to comply with applicable
data security and retention requirements. Quantum is not responsible for the
proper and complete transmission of the substance of this communication or for
any delay in its receipt.
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
