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

[Mattia Milani]

>
> 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().
>

Ok, so i was on the wrong level, i didn't see the level where there is
update-scheduled and not scheduled, my mistake.
Tomorrow i will study this parto so in the next days I'll be able to
implement it.

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).
>

Did you mean that if I develop MRAI on per-conn level there will be this
problem? In that case yeah I agree with that.
But my final goal it's to implement it for every route that i learn and i
want to shar, like RFC say.


> 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.
>

Ok i this could be the next step, first of all i will develop the simple
solution, after the tests that works fine I'll develop the complete
solution for that.

Thanks you for the help, if in the next days you have bettere ideas please
notify me.

Thanks,
Mattia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20180705/b44619ca/attachment.html>