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

Pieter Hintjens ph at imatix.com
Thu Jun 16 14:19:03 CEST 2011

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.


More information about the zeromq-dev mailing list