[zeromq-dev] How to read client's IP address from zmqsocket using tcp

[Yi Ding]

Hi,

Saw this thread in the archives.  Has there been any work done on
this?  I'd also find it pretty useful for creating a directory server,
as described in the guide.  (the example in the guide provides a way
to respond to requests but does not provide a way to actually create
the directory)

Thanks,
Yi

----

On Thu, Jun 16, 2011 at 14:19 AM Pieter Hintjens wrote:

On Thu, Jun 16, 2011 at 10:36 AM, Maciej Gajewski
<Maciej.Gajewski at tibra.com> wrote:

> But still it would be possible (and very usefull) to get address of origin of received message. Or - in case of ROUTER socket - have a mechanism that would translate the sender identity in the first message part into actual source address.

Interesting thread, because I'm looking at ROUTER emulation for the
VTX layer, and the natural key for a connection is the remote
hostnbr:port. This is in fact what I'd like to use as the identity. It
has the  advantage of being free to compute, and being transient (for
UDP and TCP at least).

It also seems to make sense to expose the origin of any message,
consider the need to log hostile payloads.

So I have two design proposals:

1. If we allow all input socket types (ROUTER, DEALER, SUB, PULL,
PAIR) to return the identity of the last sender, we get a neat API for
ROUTER, using a get/setsockopt to get/set the peer identity for recv
and send. This is much nicer than using the first message part IMO,
especially if it's orthogonal across all socket types.

2. Instead of returning a totally opaque identity, we return a
*schemed printable identity*. Printable is critical IMO for logging.
Schemed means each transport can format its own identity as needed,
and we remain free to tweak this to use short opaque identities for
e.g. compactness. I'd suggest the schemes be the same as the transport
schemes (tcp://, etc.) with appropriate formats for each (e.g.
tcp://hostnbr:port), and an id:// scheme for opaque identities.

The second proposal can be done without any API change, so I'm going
to explore that in VTX. The first proposal would require changes to
the way ROUTER works but be worth it. Note that proposal 1 also
eliminates the use of ROUTER in multi-hop scenarios, which is valid
IMO, that's XREP's job.

-Pieter