TCP keepalive only applies to idle connections. Its purpose primarily
for cases where the local process waits for data from the peer
indefinitely. If the peer disappears or reboots, the connection can tie
up resources forever, so you need a keepalive. However, if the local
TCP sends data, th
Binary tcpdumps (-w flag) are much more useful if you can get them.
Thanks,
-John
Eero Volotinen wrote:
dump while trying to transfer file via ftp:
http://zapp.pronics.fi/~eero/mirrors/dumppia
--
Eero
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body
Brian Candler wrote:
On Wed, Nov 29, 2006 at 06:08:51PM -0500, John Heffner wrote:
A couple things to keep in mind. One, if you are sending something
larger than the interface MTU (or the current route cache MTU), you will
not get an ICMP Can't Fragment from anything, and hence no EMS
Brian Candler wrote:
On Wed, Nov 29, 2006 at 12:18:55PM -0500, John Heffner wrote:
- can someone explain the rationale for Linux's behaviour?
The EMSGSIZE error is not fatal -- you can ignore it and try again, and
Linux will do the fragmentation for you.
Ah, that explains the behaviour
Brian Candler wrote:
So I was just wondering:
- can someone explain the rationale for Linux's behaviour?
The EMSGSIZE error is not fatal -- you can ignore it and try again, and
Linux will do the fragmentation for you. EMSGSIZE is generated when an
ICMP Can't Fragment is received, indicating
[EMAIL PROTECTED] wrote:
Hi,
I am running a client/server test app over IPOIB in which the client sends
a certain amount of data to the server. When the transmittion ends, the
server prints the bandwidth and how much data it received. I can see that
the server reports it received about 60% that t
On Sep 2, 2005, at 10:33 AM, [EMAIL PROTECTED] wrote:
On Fri, 2 Sep 2005, John Heffner wrote:
Have you tried increasing the size of the receive buffer yet?
Actually, I just did. I changed rmem_max and rmem_default to 4MB and
tcp_rmem to "64k 4MB 4MB". It did seem to help, but I&#
On Sep 2, 2005, at 9:48 AM, Alexey Kuznetsov wrote:
Hello!
If you overflow the socket's memory bound, it ends up calling
tcp_clamp_window(). (I'm not sure this is really the right thing to
do
here before trying to collapse the queue.)
Collapsing is too expensive procedure, it is rather an
On Sep 2, 2005, at 9:52 AM, Alexey Kuznetsov wrote:
Hello!
I experienced the very same problem but with window size going all the
way down to just a few bytes (14 bytes). dump files available upon
requests :)
I do request.
TCP is not allowed to reduce window to a value less than 2*MSS no
m
On Sep 2, 2005, at 10:05 AM, [EMAIL PROTECTED] wrote:
This particular Win2k sender sends _only_ real-time data, it's not
capable of rewinding. So it's always sending small packets, from start
to finish, yet the problem still occurs.
Note that even real-time data can end up generating a stream
On Sep 1, 2005, at 6:53 PM, Ion Badulescu wrote:
A few minutes later it has finally caught up to present time and it
starts receiving smaller packets containing real-time data. The TCP
window is still 16534 at this point.
[tcpdump output removed]
This is where things start going bad. The wi
On Tue, 22 Feb 2005, Stephen Hemminger wrote:
> On Tue, 22 Feb 2005 15:34:42 +0100
> Daniele Lacamera <[EMAIL PROTECTED]> wrote:
>
> > One last note: IMHO we really need a better way to select congestion
> > avoidance scheme between those available, instead of switching each one
> > on and off. I.
12 matches
Mail list logo
