[radvd-devel-l] mdelay
Reuben Hawkins
reubenhwk at gmail.com
Mon Dec 28 11:22:19 EST 2009
Understood. mdelay calls select with no files and just a wait time.
This pauses execution for the whole process during the delay. Would
it be better to schedule a new RA on that interface msecs in the
future rather than block the whole process?
On Sun, Dec 27, 2009 at 11:41 PM, Pekka Savola <pekkas at netcore.fi> wrote:
> On Thu, 24 Dec 2009, Reuben Hawkins wrote:
>>
>> Can somebody explain to me what the random delays are? I don't
>> understand why we would wait for any reason getting a response to a
>> request... Shouldn't a request go out as soon as possible? What am I
>> missing?
>
>> From RFC4861,
>
> random delay
> - when sending out messages, it is sometimes necessary to
> delay a transmission for a random amount of time in
> order to prevent multiple nodes from transmitting at
> exactly the same time, or to prevent long-range
> periodic transmissions from synchronizing with each
> other [SYNC]. When a random component is required, a
> node calculates the actual delay in such a way that the
> computed delay forms a uniformly distributed random
> value that falls between the specified minimum and
> maximum delay times. The implementor must take care to
> ensure that the granularity of the calculated random
> component and the resolution of the timer used are both
> high enough to ensure that the probability of multiple
> nodes delaying the same amount of time is small.
>
>
> This has been employed in both client and router side. On client side, it
> could easily be argued that on a link with lots of hosts, some random delay
> is warranted. On router side it seems a bit of exaggeration, but this is a
> MUST requirement in the spec (S 6.2.6 of RFC4861) and our implementation
> would not be compliant with the spec if it was omitted.
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> --
> radvd-devel-l mailing list : radvd-devel-l at litech.org
> http://lists.litech.org/listinfo/radvd-devel-l
>
More information about the radvd-devel-l
mailing list