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