Thu, Jun 07, 2001 at 20:18:46, gbarr (Graham Barr) wrote about "Re: read(2) and
ETIMEDOUT":
> > I'm quite sure ETIMEDOUT is a result of hitting the setsockopt
> > SO_RCVTIMEO value when doing a read.
> I had been thinking along those lines too. But immediately before calling
> read, select said there was data to read, So it should not block, but
> read what data is there and return.
This is ideological error from you: select does _not_ say "there is data
to read", it only says "read() will not block". EOF (when read() returns 0)
and any situation where read() returns -1-and-errno also are such.
But, this error does not (I think) influe to produce ETIMEDOUTs.
> Also why does this happen only every few hours ? There is a lot of
> data going through these connections maybe the timer for SO_RCVTIMEO
> is not being reset.
You should determine exact cases where ETIMEDOUT occurs.
netch@iv:/usr/REL4/src/sys/netinet>fgrep ETIMEDOUT *.c
tcp_input.c: tcp_drop(sototcpcb(so2), ETIMEDOUT);
tcp_subr.c: if (errno == ETIMEDOUT && tp->t_softerror)
tcp_timer.c: tp = tcp_drop(tp, ETIMEDOUT);
tcp_timer.c: tp = tcp_drop(tp, ETIMEDOUT);
tcp_timer.c: tp->t_softerror : ETIMEDOUT);
Add debug printf()s with __LINE__, __FILE__, variables used by stack
to make solution to drop connection. Collect statistics.
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
