In article <[EMAIL PROTECTED]> you wrote:
> Well, consider the scenario of an application which opens a control connection
> and a data connection, and the data connection remains idle for some hours
> while you get to the beginning of the queue, and then the transfer starts. The
> data
In article [EMAIL PROTECTED] you wrote:
Well, consider the scenario of an application which opens a control connection
and a data connection, and the data connection remains idle for some hours
while you get to the beginning of the queue, and then the transfer starts. The
data connection is
Cesar Barros wrote:
> On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
> > If the administrator of the NAT meant for you to have a
> > permanent mapping,
> > she would have put one there. Using keepalives to hold a NAT entry open
> > indefinitely without activity would be
On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
>
> > On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
>
> > > > This means that keepalive is useless for keeping alive more than
> > > > one connection
> > > > to a given host.
>
> > > Actually, keepalive is
> On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
> > > This means that keepalive is useless for keeping alive more than
> > > one connection
> > > to a given host.
> > Actually, keepalive is useless for keeping connections
> > alive anyway. It's
> > very badly named. It's
On Mon, Dec 25, 2000 at 04:27:07PM +0100, Igmar Palsenberg wrote:
>
> > Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
> > (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
> > somewhere). I'm trying to convince the sysadmin to raise
> Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
> (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
> somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
> bet it'll be hard.
ipchains -S timeoutval 0 0 is
Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
(according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
bet it'll be hard.
ipchains -S timeoutval 0 0 is the
On Mon, Dec 25, 2000 at 04:27:07PM +0100, Igmar Palsenberg wrote:
Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
(according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
somewhere). I'm trying to convince the sysadmin to raise it to
On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
This means that keepalive is useless for keeping alive more than
one connection
to a given host.
Actually, keepalive is useless for keeping connections
alive anyway. It's
very badly named. It's purpose is to
On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
This means that keepalive is useless for keeping alive more than
one connection
to a given host.
Actually, keepalive is useless for keeping
Cesar Barros wrote:
On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
If the administrator of the NAT meant for you to have a
permanent mapping,
she would have put one there. Using keepalives to hold a NAT entry open
indefinitely without activity would be considered
On Sun, Dec 24, 2000 at 10:14:55AM +0100, Andi Kleen wrote:
> On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote:
> >
> > I've been doing some experiments with the keepalive code in 2.4.0-test10 here
> > (I want to avoid the 2.2.x NAT I'm using (for which I don't have root)
On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote:
>
> I've been doing some experiments with the keepalive code in 2.4.0-test10 here
> (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
> timing out my connections). To test it, I reduced both
On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote:
I've been doing some experiments with the keepalive code in 2.4.0-test10 here
(I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
timing out my connections). To test it, I reduced both
On Sun, Dec 24, 2000 at 10:14:55AM +0100, Andi Kleen wrote:
On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote:
I've been doing some experiments with the keepalive code in 2.4.0-test10 here
(I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
On Sun, Dec 24, 2000 at 12:52:12PM +1100, James Morris wrote:
> On Sat, 23 Dec 2000, Cesar Eduardo Barros wrote:
>
> > Then what do you do when you are behind a NAT? And how do you expire entries in
> > ESTABLISHED state that could stay lingering forever without some sort of
> > keepalive? (The
On Sat, 23 Dec 2000, Cesar Eduardo Barros wrote:
> Then what do you do when you are behind a NAT? And how do you expire entries in
> ESTABLISHED state that could stay lingering forever without some sort of
> keepalive? (The FINs might have been lost due to a conectivity transient, so
> you can
On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
>
> > This means that keepalive is useless for keeping alive more than
> > one connection
> > to a given host.
>
> Actually, keepalive is useless for keeping connections alive anyway. It's
> very badly named. It's purpose is
> This means that keepalive is useless for keeping alive more than
> one connection
> to a given host.
Actually, keepalive is useless for keeping connections alive anyway. It's
very badly named. It's purpose is to detect dead peers, not keep peers
alive.
DS
-
To unsubscribe
I've been doing some experiments with the keepalive code in 2.4.0-test10 here
(I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
timing out my connections). To test it, I reduced both tcp_keepalive_time and
tcp_keepalive_intvl to 1. Using ethereal, I saw that the
I've been doing some experiments with the keepalive code in 2.4.0-test10 here
(I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
timing out my connections). To test it, I reduced both tcp_keepalive_time and
tcp_keepalive_intvl to 1. Using ethereal, I saw that the
This means that keepalive is useless for keeping alive more than
one connection
to a given host.
Actually, keepalive is useless for keeping connections alive anyway. It's
very badly named. It's purpose is to detect dead peers, not keep peers
alive.
DS
-
To unsubscribe from
On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
This means that keepalive is useless for keeping alive more than
one connection
to a given host.
Actually, keepalive is useless for keeping connections alive anyway. It's
very badly named. It's purpose is to detect
On Sat, 23 Dec 2000, Cesar Eduardo Barros wrote:
Then what do you do when you are behind a NAT? And how do you expire entries in
ESTABLISHED state that could stay lingering forever without some sort of
keepalive? (The FINs might have been lost due to a conectivity transient, so
you can have
On Sun, Dec 24, 2000 at 12:52:12PM +1100, James Morris wrote:
On Sat, 23 Dec 2000, Cesar Eduardo Barros wrote:
Then what do you do when you are behind a NAT? And how do you expire entries in
ESTABLISHED state that could stay lingering forever without some sort of
keepalive? (The FINs
26 matches
Mail list logo
