lkml.org 
[lkml]   [2006]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: TCP stack behaviour question
Date
From: On Behalf Of Andi Kleen

Thanks for replying, I appreciate it.

> Stevens is a good reference to BSD networking, but not
> necessarily to Linux.

Which is why I posted here. I was wondering about the specific
implementation.

What happened was this: I had a run where I captured output with
tcpdump. My original post was based on that, and the results of the
debug output from my app. For whatever reason, it appears the stack
didn't generate all of the packets it should have. When the log showed
a second-last to last retransmit time of about 27 seconds, and then a
gap of about 400 to the very next packet of any kind, I assumed that
meant the stack had given up on the retransmits when it appears
something else was going on.

I did some digging into the kernel and on the next run found that all
the expected retransmit packets were being generated, and that once
the stack gives up on the retransmits then system calls return errors.

> > Question 2a: How can my app find out the EHOSTUNREACH error
> > immediately? IP_RECVERR is not implemented on TCP, and
> SO_ERROR always
> > reports no error (0).
>
> Did you really read the manpages? It is implemented and it's
> documented.

Yes I did and no it's not, according to the man page. I quoth:
# man 7 ip
..
Note that TCP has no error queue; MSG_ERRQUEUE is
illegal on SOCK_STREAM sockets. Thus all errors are returned by
socket function return or SO_ERROR only.

Maybe the man page is wrong? That's from my FC 3 install.

..Stu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-09-18 15:23    [W:0.735 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site