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

[Helge Früh]

Hi,

I wonder if it's possible to read the client's IP address from a
zmqsocket which is connected through tcp. I know that the server socket
generates an abstract SenderId if the client doesn't use an explicit
identity. But this seems to be rather some type of GUID. I know that I
could make the client's IP address an explicit part of the message but I
would rather read the IP address of some kind of metadata that the
socket generates...

Any ideas?

-Helge
_______________________________________________
zeromq-dev mailing list
zerom...@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[Martin Sustrik]

Hi Helge,

> I wonder if it's possible to read the client's IP address from a
> zmqsocket which is connected through tcp. I know that the server socket
> generates an abstract SenderId if the client doesn't use an explicit
> identity. But this seems to be rather some type of GUID. I know that I
> could make the client's IP address an explicit part of the message but I
> would rather read the IP address of some kind of metadata that the
> socket generates...

No there's no way to find out. Given that each 0MQ socket can have 0 to
N underlying TCP or non-TCP connections, it doesn't even make much sense.

Martin

[Maciej Gajewski]

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.

This is one of the limitations of 0MQ I encountered in a project I'm working on: I'm not able to tell from what machine the request originated. It could be done on application level, but I: it adds extra complexity to the protocol on app level and II: client does not always known it's public IP address (or can not obtain this information in easy, portable way). And the router socket has all the data I need, there is only now way of extracting it.

Hi Helge,

Tibra Trading Europe Limited is Authorised and Regulated by the FSA (Company No. 06061713)
Tibra Global Services Pty Limited London Branch (Company No. BR014370)
Tibra Equities Europe Limited (Company No. 07283912)
Registered in England & Wales - Level 11, 5 Aldermanbury Square London EC2V 7HR

The contents of this email including any attachments are confidential. If you have received this email in error, please advise the sender by return email and delete this email. Any unauthorised use of the contents of the email is prohibited and you must not disseminate, copy or distribute the message or use the information contained in the email or its attachments in any way.

The views or opinions expressed are the author's own and may not reflect the views or opinions of Tibra. Tibra does not guarantee the integrity of any emails or attached files. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.

[Pieter Hintjens]

On Thu, Jun 16, 2011 at 10:36 AM, Maciej Gajewski
<Maciej....@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