[ee122] weird MNL behavior
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
> > and FD_ISSET returns true implying that there is data to be read, so I
> > 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.
> I'm not online much today, so I'm not sure if I'll be able to reply before
> > 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ee122