For developer, required some explanation on code with timer and BGP

[Ondrej Zajicek]

On Thu, Jul 05, 2018 at 05:19:33PM +0200, Mattia Milani wrote:
> Hello all, this is a message for developer and who know how bird use timer,
> and buffer.
> Sorry for the length of this mail.
> 
> For first, the protocol i want to modify and upgrade is BGP, i see that
> there isn't the timer MRAI implemented and it will be useful for some
> studies on information propagation, so i decided to develop a first version
> of it.
> 
> The actual process to send any kind of pkt is to call the function
> 
> bgp_fire_tx() and it's called by two other function respectively
> bgp_kick_tx() and bgp_tx()

Hi

If you want to implement per-conn MRAI timer, you should not do that on
level of *_tx() functions (as they handle all packets), but one level
before that - you could enforce MRAI intervals between update-scheduled
and update-not-scheduled states.

Update-scheduled state starts when bgp_rt_notify() calls
bgp_schedule_packet(p->conn, PKT_UPDATE) and ends when
conn->packets_to_send is set to zero in bgp_fire_tx().

You could ensure that there is MRAI interval between last update cycle and
new one by postponing bgp_schedule_packet(p->conn, PKT_UPDATE) when
necessary (i.e. if it is not currently sheduled and it is less that MRAI
from last end).

It is not completely correct (as you can get new route update even before
the cycle in which the previous one was already sent is finished).

The even better and correct way would be to implement it one more level before
when prefixes (in struct bgp_prefix) are dispatched for struct bgp_bucket.
There could be timestamps in struct bgp_prefix, separate queue for
bgp_buckets that contain only postponed bgp_prefixes, and list of recently
sent but not yet collected bgp_prefixes to keep their timestamps. But that
would be significantly more work.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."