Hi Roy,

On Sun, Jan 23, 2011 at 10:04:57AM -0500, Roy Smith wrote:
> Cool.  What can I do to help?

Could you try to identify precisely how it would be used at your site ?
Try to think about these cases :
  - what to do with reqids that are already present in requests
    => probably remove them at the border, forward or complete them for
       ingress instances.
  - what to do with reqids in responses
    => compare them with the request's, block if they do not match
    => delete them or not depending on where you're responding
  - what to log
    => do we always need to log a full reqid or can we sometimes just
       log one part of it
  - what info to include in it. One of my customers has designed one years
    ago and has been asking for its integration into haproxy. Lack of time
    and priorities, etc... It basically includes src ip+port, dest ip+port,
    instance name, timestamp, pid and counter. I identified that it had to
    be extended to support IPv6 and possibly more than 64k req/s/instance.
    Overall I'm fine with it because it has permitted to trace requests
    through a long chain for years. But maybe you have different needs that
    should be studied before something is implemented. For instance, it's
    possible that some users might prefer to hash it so that info present
    in it cannot be reversed when passing it to external service providers.

I think you get the idea. Try to think with multiple levels. I'm intereted
in what you can identify for your planned usage, eventhough I suspect that
it will more or less match what is described above.

Regards,
Willy


Reply via email to