<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    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.<br>
    <br>
    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. <br>
    <br>
    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.<br>
    <br>
    RBLing aside, I think both of these scenarios would be significantly
    helped by either:<br>
    1) a call that retrieves the peer address info of the pipe
    associated with the most recent 'recv' oriented call completion<br>
    2) the addition of a parameter on the 'recv' oriented calls to
    return the peer address info<br>
    3) a new property of a message conveying peer address info that
    could be retrieved via zmq_msg_get<br>
    <br>
    All thoughts welcome!<br>
    <br>
    - Stuart<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>