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

[sean finney]

hi,

On Thu, 2007-04-05 at 11:21 -0700, Thomas Guyot-Sionnest wrote:
> > but i still don't see why you need to store the header packets for
> > lookup purposes (esp in a linked list), when you already know 
> > implicitly
> > where the packets are coming from (i.e. which socket you're reading
> > from).
> 
> 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?


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20070405/cc1b2e57/attachment.sig>