monit-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UDP socket tests useless


From: Nils Ohlmeier
Subject: Re: UDP socket tests useless
Date: Tue, 13 Aug 2002 04:34:28 +0200
User-agent: KMail/1.4.2

On Monday 12 August 2002 20:39, Jan-Henrik Haukeland wrote:
> Jan-Henrik Haukeland <address@hidden> writes:
> > You're absolutely right about the select, but since monit connect the
> > udp socket a simple read on the socket should in theory return an
> > error (ECONNREFUSED) if the server is not running. It should be
> > possible to add such a default test in monit (replacing the select
> > test for UDP sockets).
>
> Just to prove my point I have enclosed a prototype of the new
> default.c test for an UDP server. This is just a test and by all means
> no final code.
>
> Test in monitrc:
>
>  port type udp 111 # Should return ok if rpc is running
>  port type udp 999 # Will fail assuming no udp server is running on port
> 999
First of this new notation above does not work ;-))

Okay you write something to the udp socket (one byte or to be more precise one 
character). If you write something to the socket a following read will return 
(icmp) errors from the sending before.
This is like a very basic default protocol test :-) and as i said my criticism 
concern only test without a protocol. If you test a protocol you wont have a 
problem.

Sending one byte to the destination is a solution, but leads to protocol 
errors on the listening side (i don't know any protocol with only one byte). 
So if you take this solution into your code (which is definitly better than 
doing nothing) it should be mentioned in the documentation, that every udp 
connection test can produce a protocol error of the listening service.

But i also don't know any better solution. For that reason i would take this 
solution and add a section to the documentation which describes the possible 
problems.

While testing your solution i observed that every test sends to packets to the 
destination. Two nearly same packets with a distance of nearly one second. 
But i don't why this happens. Maybe you have an idea where this comes from.

Greetings
   Nils Ohlmeier





reply via email to

[Prev in Thread] Current Thread [Next in Thread]