Hello,
When sending UDP, one should never expect the packets to be received
by the intended recipient, etc. But can one guarantee that NetBSD itself
won't toss away any UDP packets being sent using sendto(2)? (I.e. packet
losses are only a worry once the packet has actually left the kernel on
its way to the NIC/cable)?
If the answer is yes, then the further questions below are mostly
irrelevant.
I understand what EVFILT_WRITE does on a TCP socket (kqueue(2) is
quite clear on it). But does it do anything (useful) for UDP?
I have an application which uses libevent to read incoming TCP and
UDP traffic. The code uses libevent (which implies kqueue) when writing
data via TCP. But currently UDP packets are sent using sendto() directly
in loops similar to:
tries = 0;
do {
if tries > 0
sleep
rc = sendto(sock, ...);
tries++;
} while((rc is EAGAIN || EWOULDBLOCK || ENOBUFS) && tries < 8)
kqueue(2) stipulates, for EVFILT_WRITE:
``Takes a descriptor as the identifier, and returns whenever
it is possible to write to the descriptor. For sockets,
pipes, fifos, and ttys, data will contain the amount of
space remaining in the write buffer. [---]''
I'm not sure how "amount of space remaining in the write buffer"
translates to the UDP.
What I'm wondering is if there's any benefit to queueing the packets
in a pipeline and let libevent (implied: kqueue) send them when it
generates a write event. (Does it even do that?).
My question essentially boils down to: Do losses occur on the local
system (before the packet reaches the NIC/cable), and if so, can kqueue
in any way help mitigate that?
--
Kind regards,
Jan Danielsson
Attachment:
signature.asc
Description: OpenPGP digital signature