[zeromq-dev] Visibility into pipes of a socket

[Stuart Brandt]

After a fair amount of time looking at ZeroMQ, I'm still at a loss to 
understand how to cover certain requirements without much visibility 
into the connections/pipes that comprise a socket.  Given that the 
introduction of zmq_ctx_set_monitor seems to be significant positive 
step in that direction, I thought I'd throw out a couple scenarios to 
see if anyone has any good solutions on how to handle them.

1) Let's say I have an X/REQ socket through which requests are sent to a 
set of 'n' servers. My code detects that the standard deviation for 
response latency has been trending up, and in fact it seems like 1/nth 
of the responses have 4x the normal latency. In an ideal world, my code 
would be able to do some analysis of the issue to include correlation of 
latency to server/path and throw an alarm to an OPS type with 
information about network path and/or server that is out significantly 
out of norm.

2) Flipping scenario 1, let's say I have a server that notices 1/nth of 
the requests it's been getting in the past hour are "bad' -- either 
malformed or in violation of some app-level authentication or 
authorization check. I'd really like my server to log these as an 
abnormality, incl. originating IP + request data, so that I could 
troubleshoot further. Taking it a step further, it would also be good if 
I could correlate these "bad" requests to a particular client/IP and 
force-drop the connection from the bind side. And yet another step 
further, it would be good if I could effectively RBL the IP so that my 
server could minimize the impact the rogue client might have should it 
repeatedly try to reconnect.

RBLing aside, I think both of these scenarios would be significantly 
helped by either:
1) a call that retrieves the peer address info of the pipe associated 
with the most recent 'recv' oriented call completion
2) the addition of a parameter on the 'recv' oriented calls to return 
the peer address info
3) a new property of a message conveying peer address info that could be 
retrieved via zmq_msg_get

All thoughts welcome!

- Stuart








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120920/cbc22bde/attachment.htm>