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