In article <20040209134657.GA29877@zhwin.ch>,
Christoph Kaegi <kgc@zhwin.ch> wrote:
>
>Dear NetBSDers
>
>I have been running a small, homegrown distributed monitoring system 
>on my (mostly NetBSD) unix hosts for several months now.
>It consists of a master on one host and an agent on every watched host.
>
>A state query client asks over a Unix Domain UDP Socket for the
>actual state and receives statereplies, one UDP Packet for every 
>state monitored.
>
>Today, I added the 172th probe, and now, when the master is sending
>the states down the socket, sendto(2) returns EINVAL, when trying to 
>send the 172th UDP packet.
>
>The sendto(2) manpage says:
>
>     [EINVAL]      The total length of the I/O is more than can be expressed
>                   by the ssize_t return value.
>
>... which doesn't seem to be my problem, as the messages are
>constant sized (321 Bytes)
>
>I am thinking, that the problem could be, that the master just 
>sends all the states out the (non-blocking) socket and is hitting 
>a resource limit somewhere.
>
>So I have the following questions:
>
>- How do I go about pacing sendto(2) on a non-blocking socket?

select/poll to see if you can write to it?

>- Is sendto(2) giving me a misleading/wrong error message? 
>  Or is the sendto(2) manpage not concise enough?

Yes, it is. There are many places in the sendto() code where EINVAL
can be returned. The only way that you can figure it out, is to add
printfs and recompile the kernel.

christos