[Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding)

[Thomas Guyot-Sionnest]

> -----Original Message-----
> From: nagiosplug-devel-bounces at lists.sourceforge.net 
> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On 
> Behalf Of sean finney
> Sent: April 5, 2007 16:11
> To: Nagios Plugin Development Mailing List
> Subject: Re: [Nagiosplug-devel] check_ntp (Was: Flight 
> 1.4.8,ready for boarding)
> 
> hi,
> 
> > 
> > UDP is not a connection-oriented protocol. It will take 
> anything suposedly
> > sent from the remote ip/port to the local ip/port and 
> packet ordering is not
> > guarenteed. What if earlier in the plugin you decided that 
> some packet was
> > not coming back, but some routing issues on the network 
> made it come back a
> 
> if you only send offset requests through an fd, you only get offset
> responses through the fd.  if you have a different fd for the readstat
> requests (via a new socket while the previous one was open, bind(), or
> maybe setsockopt) then you don't have to worry about the ordering,
> without the use of any extra data structures (besides an array or
> two).  
> 
> but maybe this is all moot... has anyone looked to see how 
> hard it'd be
> to just determine the packet type from the contents?  i.e. if you're
> waiting for readstat responses and a stale packet comes in, 
> couldn't it
> just be discarded?  for example, in the print_offset_request 
> function i
> see something like:
> 
> if(p->op&REM_RESP && p->op&OP_READSTAT){
> 
> so couldn't that check be used to filter out any possible 
> stale packets?
> 
> so like:
> 		
> 		DBG(printf("recieving READSTAT response"))
>                 read(conn, &req, SIZEOF_NTPCM(req));
>                 DBG(print_ntp_control_message(&req));
> +		if(p->op&REM_RESP && p->op&OP_READSTAT) {
>                 /* Each peer identifier is 4 bytes in the 
> data section,
> which
>                  * we represent as a ntp_assoc_status_pair datatype.
>                  */
> ...
> +		}
> 
> or maybe something better in case the bits at the same spot 
> in a offset
> message weren't predictable?

I was rather thinking of adding ntp read and write functions that takes a
pointer to the structure you want to send/receive and the linked list. On
write it will send the packet then append a node to the linked list with
some of the headers on success. On read it will remove the matching node
from the list, drop the request if the packet is not matched, then check the
error field. The return status could be used to induce various behavior
(i.e. error, unmatched, nothing to read (empty list or packets too old)).

Anyways let me first see how I'm gonna work it out to: 1) Allow multiple
servers to be specified on the command line, and 2) make the jitter check
run on every host found.

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3076 bytes
Desc: not available
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20070405/ba030889/attachment.bin>