Thanks for the response. Comments inline....
On 9/21/12 12:05 AM, Pieter Hintjens wrote:
> On Thu, Sep 20, 2012 at 9:40 PM, Stuart Brandt <s...@compuserve.com> wrote:
>
>> All thoughts welcome!
> Very roughly, trying to do this kind of thing is why it takes people
> months to write even basic protocols over TCP. No layering.
I'm a little puzzled on this statement. The API for 3.x has peer address
transiting both into and out of the 0MQ library layer. Exposing the
transport origin of a received message using the same philosophy as
zmq_ctx_set_monitor (an after-the-fact thing intended for monitoring and
operational concerns) doesn't strike me as a layering violation given
0MQ's existing APIs.
> Logging IP
> addresses in the server?
Absolutely! Operational auditing, monitoring, and troubleshooting is a
real PITA without it. Peer address info, or at least peer IP, is pretty
much standard monitoring info in most distributed apps I've seen.
> Measuring latency of servers?
Yes. Again this is one of those operational kinds of things. Measuring
server latency is a valuable tool for identifying issues that need to be
raised to operations staff.
>
> Most of what you want to achieve can be done easily above 0MQ by
> ignoring the physical network and talking application to application.
> Heartbeats from servers to clients. Application-level identifiers.
Agreed...but only if you assume a well behaved app-level that never runs
into version mismatch problems, or questionable/rogue peers, or word
boundary alignment problems, or any of a variety of application problems
that could pollute an app-level identifier. There are a lot of great
lessons in The Guide, and in this case the part on reliability that
cites application code as the worst offender when it comes to
reliability seems to apply. I'm not looking to guard against a hacker
working at the TCP or even ZMTP layer here. Protection against that is
well beyond the scope of 0MQ. I am, however, looking to make sure that
when some new client code makes it into production with a buffer
overwrite bug that my server can log/alarm with enough specifics to be
useful. Given the choice between
2012-09-24 14:25:51,644 ERROR - Unrecognized request from peer
192.0.0.1:12234
and
2012-09-24 14:25:51,644 ERROR - Unrecognized request from peer
#^2ffwi23r098vnasdf0
which would you prefer to use for quickly finding the client instance
that went bad?
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
