[ee122] weird MNL behavior

Amit Matani amitmatani at berkeley.edu
Sun Dec 9 18:33:39 PST 2007

Wow, I found it and I am a complete idiot.  My RTO estimator sometimes
generated a microsecond field of greater than 1 million.  This causes select
to fail.  Thanks for the help.


On Dec 9, 2007 4:53 PM, <vern at cs.berkeley.edu> wrote:

> > I am using select to wake me up on a timeout or if there is data ready
> to be
> > received.  Towards the end of the transfer, select returns before a
> timeout
> > and FD_ISSET returns true implying that there is data to be read, so I
> call
> > recvfrom which ends up blocking which would imply that there is nothing
> > there.
> In my experience, this is pretty much always some sort of bug in the use
> of select, though they can sometimes be very hard to find.  You've already
> taken care of the #1 suspect, which is failing to FD_ZERO or failing to
> FD_SET correctly.  Another possibility is that your code is structured to
> (somewhere internal) read from the fd that you're then later trying to
> read due to select(), so that now it no longer has anything to return;
> or you're reading with recvfrom and what you've specified doesn't match
> the packet that came in.
> If you send me your select() loop, I'll try to take a look at it.
>  However,
> I'm not online much today, so I'm not sure if I'll be able to reply before
> tomorrow.
> > I read online that select does not guarantee that recvfrom wont
> > block because the packet may have been corrupted.
> That doesn't sound right to me - the kernel should make the integrity
> checks
> prior to analyzing the rest of the header, and it has to do that analysis
> in order to figure out which file descriptor to flag as being available
> for reading.  (More generally, servers all over the world rely on select()
> not causing them to occasionally block waiting to read - so this is code
> that has *really* been hammered on.)
> > So I changed my socket to
> > work in non-blocking mode.
> Do try to avoid that.  Like select(), it comes with its own subtle usage
> errors, and the combination can be quite confusing.
> It's worth stepping through the code executed by MNL for the recv to
> see whether in some cases it reads twice or something like that.
>                Vern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/66bdb73b/attachment.html 

More information about the ee122 mailing list