On Friday 30 April 2010, David Sommerseth wrote: > >> I agree that that would be a wise change. However, I wonder: why change > >> the amount of bytes, if you can also simply not count the ping packets? > >> To me, it would seem a much more accurate way of determining whether the > >> connection is idle or not, because there's always the possibility of > >> duplicate ping packets (even although that's unlikely) or other errors. > >> Or would that cause a too great load on the server? > > > > Sounds like a good idea. Do any devs have an idea how difficult > > (code-vise) that'd be? > > I've not gone too deep into this code path yet, but I believe from what > I could see, the byte counter is located on a different place than the > "ping initiator". That means that telling the "byte counter code" that > "this is our own packet, don't count it" is not as trivial to fix as it > sounds like. > > It looks like we just put 16 bytes of "static randomness" (defined in > ping.c) and push that into the some session buffers. Then later on, in > another function pushes what ever is queued up for transmission. > > But this need to be investigated further ... and if someone is quicker > than me to figure it out, patches are, as always, more than welcome!
Well, the obvious (and probably wrong, probably inefficient) way could be to just check if the packet at hand is a ping message, and if it is do not record it as "activity", eg if (! is_ping_msg (&c->c2.buf)) register_activity (c, size); This is in two places: in process_outgoing_tun() and process_outgoing_link(). However, I'm not sure about the overhead of performing that for each and every processed packet. is_ping_msg() calls buf_string_match(), which in turn calls memcmp(). But, it should also be noted that process_incoming_link() DOES call is_ping_msg() for every incoming packet, so... -- D.
