Some time ago, I put forward a proposal to this list for a way to measure lag and types of lag. I called this "AsLL," or "Asymmetric Link Latency." The idea is that you add an accurate timestamp to PING in the server->server exchange. When an AsLL-enabled server receives this PING, it'll return a PONG containing the original timestamp and the time difference with its own clock that was measured and its own timestamp. To complete an AsLL exchange, the first server sends back another PONG containing the second server's timestamp and the measured RTT. These AsLL PING/PONGs are differentiated from each other and from the "standard" exchange by the number of arguments being sent.
Implementing this feature will first require adding appropriate data elements to the link description structures and providing a way to query that data. As part of this, we may wish to provide a new command that can return the current sendq for a link as well as the one-way link latency and RTT--the advantage of adding (yet another) new command is that we can leverage the priority queue mechanism to enable the command and its reply to run ahead of the lag. If you look at ircd/m_ping.c, you'll note this comment: /* * Extension notes * * <Vek> bleep: here's the change you make to PING: * <Vek> F TOK_PING F G 7777777777.7777777 * <Vek> then optional parameter for further enhancement * <Vek> G TOK_PONG G F 7777777777.7777777 0.1734637 */ This is a starting point. It's up to you to figure out what the new exchange is going to look at. A driving priority is to ensure that this will not prevent existing servers that do *not* implement this feature from properly detecting and replying to normal pings, and that servers that do implement this feature will not croak or ignore a PONG. If you make this change relative to u2.10.11, you must test carefully to make sure that no new bugs are introduced, and particularly that u2.10.10 and u2.10.11 interoperability is preserved. As before, write to this list if you're interested in pursuing this. If multiple people are interested in helping out, I encourage you to work together, particularly if one of you is more experienced than the other-- teaching new people the way around the ircu source code is one of the things I'm going for here :) -- Kevin L. Mitchell <[EMAIL PROTECTED]>
