recvfrom() and Debian
Alex Vrenios
plug-devel@lists.PLUG.phoenix.az.us
Mon Oct 21 23:31:03 2002
All,
I seek the wisdom of the group...
A simple approach to fault tolerance in receiving a UDP response to a query
is to use sendto("the_query") and then recvfrom("the_response"). You, the
client, should not trust the server, however, so you do something like the
following:
sendto("the_query");
alarm(2); /* set */
while(1)
{
recvfrom("the_response");
if(alarm_didn't_go_off)
break;
sendto("the_query");
alarm(2); /* reset */
}
alarm(0); /* cancel */
/* process the response */
Okay, maybe you want to add a counter so you don't spend the rest of your
days and nights waiting for that response, but that's not the point.
A particular release (2.2.18pre21 #1 Sat Nov 18 18:47:15 EST 2000 i686) of
Debian (via the CD in Hunger's book, titled Debian GNU/Linux Bible) behaves
oddly. Specifically, the alarm signal (SIGALRM) does -not- interrupt that
recvfrom() call. The code sits there, never getting past the recvfrom() even
after the alarm went off. (This was shown to be true with a puts() call)
just after the if/break.)
My search uncovered a TON of Debian+recvfrom problems, but nothing specific
to this issue. Does anyone support my decision to condem the OS in this
case? Is there a workaround that anyone might suggest?
Thanks in advance for any info.
Best Regards,
Alex