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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
