[ntp:questions] Re: Multicast TTL and FreeBSD trouble

[David L. Mills]

{er.

I was referring to the ttl vector and increments, which hasn't changed. 
The peer->ttl structure member is not used for its original purpose; it 
is used as a flag value for some reference clocks. The naming is 
unfortunate.

The sendpkt() semantics for ttl did change. There was no room in the 
configuration structure for a per-peer ttl mechanism, so it had to be a 
system variable. Another victim of the configuration mess.

Dave

Per Hedeland wrote:
> In article <4308D64E.6030007 at gis.net> mayer at gis.net (Danny Mayer) writes:
> 
>>David L. Mills wrote:
>>
>>>Guys,
>>>
>>>Wash your mouth with soap. The scheme does not conform to the anycast 
>>>model; it does conform to the manycast model, where the intent is to 
>>>capture a plurality of servers, not just a single one. I have not 
>>>changed the ttl code in a decade. If it behaves differently in Linux and 
>>>FreeBSD, somebody else has changed the code or the operating system has 
>>>a mind of its own.
>>>
>>>Dave
>>
>>Nothing to wash, Dave. I know it hasn't changed. I agree that getting 
>>different results on different O/S's indicates an O/S problem rather 
>>than an ntp problem. I have yet to look at the manycast model, too many 
>>other things to work on...
> 
> 
> Uh, I know that there are issues with the source code management for the
> reference implementation, but this is getting silly. Here are excerpts
> from a diff between 4.1.2 and 4.2.0, both downloaded from ftp.udel.edu:
> 
> --- ntp-4.1.2/ntpd/ntp_proto.c  Thu Jan 17 22:27:47 2002
> +++ ntp-4.2.0/ntpd/ntp_proto.c  Tue Oct  7 12:21:39 2003
> ...
>                 HTONL_FP(&peer->xmt, &xpkt.xmt);
> -               sendpkt(&peer->srcadr, peer->dstadr, peer->ttl, &xpkt,
> -                   sendlen);
> +               sendpkt(&peer->srcadr, peer->dstadr, sys_ttl[peer->ttl],
> +                   &xpkt, sendlen);
>                 peer->sent++;
> ...
>         }
> -       sendpkt(&peer->srcadr, peer->dstadr, peer->ttl, &xpkt, sendlen);
> +       sendpkt(&peer->srcadr, peer->dstadr, sys_ttl[peer->ttl], &xpkt,
> +           sendlen);
>  
> 
> Sure looks like a significant change to me... - maybe not to the
> manycast model, but then no-one has been suggesting that there are
> problems with that. The issue at hand is the semantics of the 'ttl'
> option for the 'broadcast' command.
> 
> --Per Hedeland
> per at hedeland.org