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