: This wouldn't help the poor sod whose connection gets shot down every
: eight days while he's not there and doesn't know what hit him.
: If the poor sod hasn't touched his xterm for 8 days, he's either dead
: or he doesn't care if it goes away.
:
:Again, Matt, with all due respect, please do not
On 8 Jun 1999, Joel Ray Holveck wrote:
This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.
If the poor sod hasn't touched his xterm for 8 days, he's either dead
or he doesn't care if it goes away.
Again,
Hi folks,
This thread has degenerated into the kind of dick-waving that suggests
to the responsible list member that it's no longer worth participation.
If you have nothing to say, there are many of us who would be in your
debt if you'd be so kind as to say it.
Ciao,
Sheldon.
To Unsubscribe:
Louis A. Mamakos wrote:
Before documenting it, how about we fix it's name to be more accurate
to newcomers: net.inet.tcp.always_makedead, etc. There's no part of
this (in many cases misguided) mechanism that keeps anything alive.
I believe the rationale behind the nomenclature is to ``keep
Louis A. Mamakos wrote:
Before documenting it, how about we fix it's name to be more accurate
to newcomers: net.inet.tcp.always_makedead, etc. There's no part of
this (in many cases misguided) mechanism that keeps anything alive.
I disagree. I use keepalive exactly to keep my connections
On Jun 5, 5:43pm, John-Mark Gurney wrote:
} Subject: Re: RE: net.inet.tcp.always_keepalive on as default ?
} Garrett Wollman scribbled this message on Jun 5:
} On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman
gr...@unixhelp.org said:
}
} FWIW, I think only a fool would want a computer
On Tue, Jun 08, 1999 at 06:07:23AM -0700, Don Lewis don.le...@tsc.tdk.com
wrote:
} yes, but are routers normally down for a couple hours?? if they are,
} you have other problems than worring about connections...
We've lost our T1 to the world for up to twelve hours.
Well, we had lightning
:} you have other problems than worring about connections...
:
:We've lost our T1 to the world for up to twelve hours.
And at the time, which was more important: Getting the T1 back up, or
keeping all those idle xterm's around? If it were my T1 that went down,
I wouldn't give a damn
On Tue, Jun 08, 1999 at 11:23:26AM -0700, Matthew Dillon
dil...@apollo.backplane.com wrote:
:We've lost our T1 to the world for up to twelve hours.
And at the time, which was more important: Getting the T1 back up, or
keeping all those idle xterm's around? If it were my T1 that
This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.
If the poor sod hasn't touched his xterm for 8 days, he's either dead
or he doesn't care if it goes away.
Again, Matt, with all due respect, please do not post
There's also the the minor nit that there's no documentation. RTSL
may be OK for developers, but it's not really appropriate for end
users. This is aggravated by the timers being in 500ms units - phk
tripped over this recently.
Before documenting it, how about we fix it's name to be more
:
:Before documenting it, how about we fix it's name to be more accurate
:to newcomers: net.inet.tcp.always_makedead, etc. There's no part of
:this (in many cases misguided) mechanism that keeps anything alive.
:
:louie
The technical term in thousands of pages of literature with millions of
: FWIW, I think only a fool would want a computer to NOT drop dead connections.
: Any connection that doesn't respond after 8 $^! tries spaced FAR apart
does
: NOT deserve to stay.
:
:If they are spaced too far apart, it is possible for perfectly
:legitimate connections to get shot down as a
:
: If they are spaced too far apart, it is possible for perfectly
: legitimate connections to get shot down as a result of external
: periodicities. (Does somebody's router reset every day at 2:45? If
: so, better hope no keepalives are scheduled for then!)
:
:But remember that the idea is the
: wouldn't notice... nobody would notice.
:
:I would. I have several long-lived connections, with a few of them
:are sometimes unreachable for quote some time. I like that they survive,
:and would hate it, if some brain-dead default would ruin my perfectly
:set up connections.
:
:Even more,
:On Sat, 5 Jun 1999 20:13:56 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
:
: If they are spaced too far apart, it is possible for perfectly
: legitimate connections to get shot down as a result of external
: periodicities. (Does somebody's router reset every day at 2:45? If
: so, better
:
: 4. It would be desirable to have per socket timeouts, but would
: require application changes which are unlikely to happen.
:
:Huh? I was just considering writing the patch for this. What
:application problems would this create?
:
:The worst thing I can see is that it would mean that
:On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote:
: QED: The following patch.
:[...]
: +tcp_keepalive=YES # Kill dead TCP connections (or NO).
:
:I still don't understand why you insist on making it YES by default. It
:works fine like it is for most of the people right
From: Matthew Dillon dil...@apollo.backplane.com
Subject: Re: net.inet.tcp.always_keepalive on as default ?
Date: Sat, 5 Jun 1999 23:20:20 -0700 (PDT)
Message-ID: 199906060620.xaa17...@apollo.backplane.com
dillon As far as dial-on-demand goes, that also makes no real difference.
dillon
:Huh? I was just considering writing the patch for this. What
:application problems would this create?
:
:The worst thing I can see is that it would mean that changing the
:timeout value on a running system wouldn't affect already opened
:sockets. Even that may be changable by an external
The poor sod in this situation deserves something untoward,
IMNSHO. Protocols like ssh do send something periodically whereas
telnet doesn't. Telnet is a well-known security problem. As others
have pointed out, this is an endemic problem in applications
generally speaking, where a long-term
On Sat, Jun 05, 1999 at 11:26:28PM -0700, Matthew Dillon wrote:
If the poor sod hasn't touched his xterm for 8 days, he's either dead
or he doesn't care if it goes away.
Thanks for your concern.
Matt, poor sod.
--
Matthew Hunt m...@astro.caltech.edu * UNIX is a lever for the
But remember that the idea is the keepalive would keep trying for a
certain amount of time, and this would be finely configureable.
Adjusting the keepalive's retry period after activation is also
irrelevant. As they currently stand, keepalives operate in virtually
[snip]
I don't see why
Joel Ray Holveck jo...@gnu.org wrote:
I don't see why this is a point of discussion. The keepalive timers
are all configurable via sysctl.
Not quite all. The variables tcp_keepcnt and tcp_maxpersistidle are
not accessible via sysctl (the latter is not directly related to the
current keepalives
David Schwartz wrote:
Well, we've heard various opinions and I think we can conclude that:
2. That server applications should have keepalives enabled.
Well, I certainly don't agree with that. Many server applications (web
servers, mail servers, etcetera) already have data
Poul-Henning Kamp once stated:
=+tcp_keepalive=YES # Kill dead TCP connections (or NO).
Mmm, probably dead TCP connections?
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
In message 199906051334.jaa12...@kot.ne.mediaone.net, Mikhail Teterin writes:
Poul-Henning Kamp once stated:
=+tcp_keepalive=YES # Kill dead TCP connections (or NO).
Mmm, probably dead TCP connections?
After 8 attempts at reaching other end: Dead TCP connections.
--
Poul-Henning Kamp
=+tcp_keepalive=YES# Kill dead TCP connections (or NO).
Mmm, probably dead TCP connections?
'inactive or dead' ?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Poul-Henning Kamp once stated:
==+tcp_keepalive=YES # Kill dead TCP connections (or NO).
=
=Mmm, probably dead TCP connections?
=
=After 8 attempts at reaching other end: Dead TCP connections.
Perhaps very probably dead? I'm just trying to prevent questions in
users' minds: why the
David Schwartz wrote:
Well, we've heard various opinions and I think we can conclude that:
2. That server applications should have keepalives enabled.
Well, I certainly don't agree with that. Many server
applications (web
servers, mail servers, etcetera) already have data
: There is no logical reason for a well-designed web server to enable
:keepalives. Of course, they don't hurt anything.
:
:...
:
: Agreed. Telnetd is the exception, keepalives are great for it. For
:everything else, almost, data timeouts make far more sense. And keepalives
:will do
FWIW, I think only a fool would want a computer to NOT drop dead connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart does
NOT deserve to stay.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
I think part of the solution is a new class of keepalives..
With this new class, a keepalive is sent every N second (3600?)
but if no response is heard, no action is taken. The only action that is
taken is if a NAK is recieved in response.
Most IP addresses woudl be re-used within a few days, so
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
FWIW, I think only a fool would want a computer to NOT drop dead connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart does
NOT deserve to stay.
If they are spaced too far apart, it
On Sat, 5 Jun 1999, Garrett Wollman wrote:
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
FWIW, I think only a fool would want a computer to NOT drop dead
connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart
does
NOT
On Fri, Jun 04, 1999 at 10:21:05PM +0200, Matthew Dillon wrote:
Around 0.02%, using the stats from one of BEST's busier servers.
That's percent.
In otherwords, nobody would notice. You wouldn't notice, the backbones
wouldn't notice... nobody would notice.
I would. I have
Garrett Wollman scribbled this message on Jun 5:
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
FWIW, I think only a fool would want a computer to NOT drop dead
connections.
Any connection that doesn't respond after 8 $^! tries spaced FAR apart
does
On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote:
QED: The following patch.
[...]
+tcp_keepalive=YES # Kill dead TCP connections (or NO).
I still don't understand why you insist on making it YES by default. It
works fine like it is for most of the people right now.
So
On Sat, 5 Jun 1999 20:13:56 -0400 (EDT), Brian Feldman gr...@unixhelp.org
said:
If they are spaced too far apart, it is possible for perfectly
legitimate connections to get shot down as a result of external
periodicities. (Does somebody's router reset every day at 2:45? If
so, better hope
This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.
One thing that no one points out is that this idle connection
is potentially a security threat. Even if the physical connection
is iced and is reconnected later
I don't know what's worse; that Microsoft themselves can't keep
Windows running for 50 days, or that they're incapable of manually
bumping the counter to a value close to UINT_MAX and wait a few
minutes for it to roll over.
What's worst is probably that the bug doesn't affect operation.
The central issue of keepalives is that, for one machine, they don't create
a significant load. Multiplied by the number of machines on the Internet,
it can become a problem.
Divided by the combined bandwidth of the networks these machines are
using, it ceases to be a problem.
joelh
--
4. It would be desirable to have per socket timeouts, but would
require application changes which are unlikely to happen.
Huh? I was just considering writing the patch for this. What
application problems would this create?
The worst thing I can see is that it would mean that changing
This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.
One thing that no one points out is that this idle connection
is potentially a security threat. Even if the physical connection
is iced and is reconnected later
On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
I think keepalive's could easily be turned on by default. At BEST, one
of the first things I did 5 years ago was to turn them on permanently
on all of our machines.
I'd like to disagree on the by default part, on the
Hi guys,
Since this isn't something everyone agrees on, how about adding a knob
to the boot time config files? This would make the keep-alive issue more
visible, and encourage folks to think about what they want.
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with
On Fri, Jun 04, 1999 at 03:32:02PM +0200, Pierre Beyssac wrote:
I don't see what this fuss is all about. If for _some_ big servers
there are many dead connections around after a while (*), why don't
THEY use a sysctl at boot-time to change the default state, rather
than impose on the rest of
In message 19990604170654.a8...@salmon.maths.tcd.ie, David Malone writes:
It might be nice to have two keepalive timeouts like Nate suggested.
You'd have a short one, which applies if the application turns on
keepalive or you have alwayskeepalive on. Then you'd have a long
one, which applies to
:On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
: I think keepalive's could easily be turned on by default. At BEST, one
: of the first things I did 5 years ago was to turn them on permanently
: on all of our machines.
:
:I'd like to disagree on the by default part,
On Fri, 4 Jun 1999 09:17:16 -0700 (PDT), Matthew Dillon
dil...@apollo.backplane.com said:
Pierre, let me make the suggestion to you that you try turning them
on. I'll bet you dollars to donoughts that you will not notice
the difference.
Except when you happen to run into one of
In message 19990604170654.a8...@salmon.maths.tcd.ie, David Malone writes:
It might be nice to have two keepalive timeouts like Nate suggested.
You'd have a short one, which applies if the application turns on
keepalive or you have alwayskeepalive on. Then you'd have a long
one, which
In message 199906041621.maa11...@khavrinen.lcs.mit.edu, Garrett Wollman
writes:
On Fri, 4 Jun 1999 09:17:16 -0700 (PDT), Matthew Dillon
dil...@apollo.backplane.com said:
Pierre, let me make the suggestion to you that you try turning them
on. I'll bet you dollars to donoughts that you
I think people just like to argue sometimes. The reality is different.
For all you people complaining: Just turn them on and I guarentee
you will not even notice the difference, except you will stop getting
( even the occassional ) stale internet server process. That is what
32bit is enought for everthing
Just mention the horrible header offset field. Lots of good TCP nits.
Anyway, can't this argument be settled by separating the mechanism and policy.
Adding a simple rc.conf tweak to enable them should be enough.
But, consider going back to the
In message 37580f03.88efb...@sitara.net, John R. LoVerso writes:
But, consider going back to the discusssions leading up to the Host
Requirements
RFC (1122). The particular problem was that the original timeout value for
keepalives was tiny (a few minutes). 1122 dictated the corrections for
At 10:03 AM 6/4/99 , Matthew Dillon wrote:
I think people just like to argue sometimes. The reality is different.
For all you people complaining: Just turn them on and I guarentee
you will not even notice the difference, except you will stop getting
( even the occassional )
At 07:56 PM 6/4/99 +0200, Poul-Henning Kamp wrote:
I still think the right thing is:
default to keepalives.
set the timeout to a week.
OpenLDAP slapd, like may other daemons, relies on timeouts being a
reasonably short (a few hours) to deal with dead streams. Dead
streams occur
In message 37580f03.88efb...@sitara.net, John R. LoVerso writes:
But, consider going back to the discusssions leading up to the Host
Requirements
RFC (1122). The particular problem was that the original timeout value for
keepalives was tiny (a few minutes). 1122 dictated the corrections for
In message 4.2.0.56.19990604111235.00ae3...@rowett.org, Kevin J. Rowett
writes:
The central issue of keepalives is that, for one machine, they don't create
a significant load. Multiplied by the number of machines on the Internet,
it can become a problem.
Reality home-work assignment to Kevin:
In message 199906041824.laa29...@implode.root.com, David Greenman writes:
In message 37580f03.88efb...@sitara.net, John R. LoVerso writes:
But, consider going back to the discusssions leading up to the Host
Requirements
RFC (1122). The particular problem was that the original timeout value for
How about this then:
net.inet.tcp.always_keepidle: 86400 /* new variable */
net.inet.tcp.always_keepintvl: 64800/* new variable */
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
net.inet.tcp.always_keepalive: 1
This will have all sockets
At 11:24 AM -0700 6/4/99, David Greenman wrote:
someone else wrote:
I still think the right thing is:
default to keepalives.
set the timeout to a week.
I don't support increasing the default timeout. That would cause
problems for a lot of server systems that rely on the
Kevin J. Rowett krow...@rowett.org writes:
The central issue of keepalives is that, for one machine, they don't
create a significant load. Multiplied by the number of machines on
the Internet, it can become a problem.
No offense, but that is the most ludicrous assertion I've heard since
:Hint: If everybody turned on TCP keepalives, what percentage of the
:traffic on Internet backbones do you think would be keepalive
:packets?
:
:Jim Shankland
:NLynx Systems, Inc.
Around 0.02%, using the stats from one of BEST's busier servers.
That's percent.
In otherwords, nobody
:had not been done, then the Internet would not have grown as it did today.
:
:The central issue of keepalives is that, for one machine, they don't create
:a significant load. Multiplied by the number of machines on the Internet,
:it can become a problem.
As I said. People are arguing about
I don't support increasing the default timeout. That would cause problems
for a lot of server systems that rely on the relatively short two hour
default.
The best I think you could do would be to increase it to something like
12-24 hours as a default, but even that might be problematical.
:
:Around 0.02%, using the stats from one of BEST's busier servers.
:That's percent.
Oops, I wrong. It's actually less then that... the network counters
overflowed. More around 0.001%. That's relative to outgoing traffic,
not relative to network capacity. And, to be nice,
In message 199906042013.naa29...@implode.root.com, David Greenman writes:
I don't support increasing the default timeout. That would cause problems
for a lot of server systems that rely on the relatively short two hour
default.
The best I think you could do would be to increase it to something
In message 37580f03.88efb...@sitara.net, John R. LoVerso writes:
But, consider going back to the discusssions leading up to the Host
Requirements
RFC (1122). The particular problem was that the original timeout value for
keepalives was tiny (a few minutes). 1122 dictated the corrections
At 01:08 PM 6/4/99 , Matthew Dillon wrote:
:had not been done, then the Internet would not have grown as it did today.
:
:The central issue of keepalives is that, for one machine, they don't create
:a significant load. Multiplied by the number of machines on the Internet,
:it can become a
Nate Williams wrote:
How about this then:
net.inet.tcp.always_keepidle: 86400 /* new variable */
net.inet.tcp.always_keepintvl: 64800/* new variable */
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
net.inet.tcp.always_keepalive: 1
This
:At 01:08 PM 6/4/99 , Matthew Dillon wrote:
::had not been done, then the Internet would not have grown as it did today.
::
::The central issue of keepalives is that, for one machine, they don't create
::a significant load. Multiplied by the number of machines on the Internet,
::it can become a
You know, I was going to buy a pickup truck, but I was afraid my
neighbors
would figure that if I bought a pickup truck, they should buy one too. And
maybe a pickup truck isn't the right vehicle for them -- perhaps they didn't
even know how to drive one safely. So I bought an Explorer
In message 199906042217.paa22...@gndrsh.aac.dev.com, Rodney W. Grimes
writes:
In message 37580f03.88efb...@sitara.net, John R. LoVerso writes:
But, consider going back to the discusssions leading up to the Host
Requirements
RFC (1122). The particular problem was that the original timeout
Well, we've heard various opinions and I think we can conclude that:
1. Even with the current timeouts, there is no significant increase
in network trafic, even with the market share FreeBSD has.
2. That server applications should have keepalives enabled.
3. That the few people, for
Well, we've heard various opinions and I think we can conclude that:
2. That server applications should have keepalives enabled.
Well, I certainly don't agree with that. Many server applications (web
servers, mail servers, etcetera) already have data timeouts, which makes
keepalives
On Wed, Jun 02, 1999 at 07:19:11PM +1200, Joe Abley wrote:
I would take issue with that. All of the regional registries require
extremely good justification for allocating static IP addresses to
transient network connections.
Demon (a big ISP in .uk) allocate static IP addresses for
On Tue, Jun 01, 1999 at 02:16:55PM -0600, Nate Williams wrote:
this is less and less of a problem because
if you lose your link on PPP
you are liable to get a differetn IP address on your redial.
Not true. Only if you're using a dynamic IP address setup. Most
business connections have
k...@lyris.com writes:
Is it that long? I honestly don't think I have ever seen one stay up for a
week. Are you sure you did not mean 48 hours? I don't speak in jest.
49.7 days until an internal millisecond counter rolls around and
crashes the machine.
Microsoft have a patch out, but according
Matthew Hunt wrote:
On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:
I think he was suggesting that the apps close the connection if they
receive no data from some amount of time. (Isn't this common sense?)
No, I frequently keep telnet/ssh connections idle for long
On Wed, Jun 02, 1999 at 10:58:41PM +0200, Andre Oppermann wrote:
Matthew Hunt wrote:
On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:
I think he was suggesting that the apps close the connection if they
receive no data from some amount of time. (Isn't this common
Considering the number of hosts on the net today, which come and
go with no warning and with dynamic IP assignments, I would propose
that we disregard what the old farts felt about TCP keepalives,
and enable the sysctl net.inet.tcp.always_keepalive as default.
Setting this will make all
Considering the number of hosts on the net today, which come and
go with no warning and with dynamic IP assignments, I would propose
that we disregard what the old farts felt about TCP keepalives,
and enable the sysctl net.inet.tcp.always_keepalive as default.
Seeing as the amount of traffic
From: Poul-Henning Kamp p...@freebsd.org
Date: Tue, 01 Jun 1999 20:41:00 +0200
Considering the number of hosts on the net today, which come and
go with no warning and with dynamic IP assignments, I would propose
that we disregard what the old farts felt about TCP keepalives,
and enable
I think it is fair to say that the nature of the internet has changed
somewhat since the standards were made. Keepalives by default are not sent
until after two hours, if they are acknowledged no more packets are sent.
If not 10 more probes are sent 75 seconds apart before the connection is
On Tue, Jun 01, 1999 at 12:40:34PM -0700, k...@lyris.com wrote:
declared dead. I think it somewhat silly to say that this is consuming a
lot of bandwidth. The average mail message (4k) is 4 packets, the average
The other issue is that you don't necessarily want the TCP connection
to close just
... and keep dynamic lines up when they should otherwise have been
allowed to fall down.
[...]
The second argument falls on the same reasoning in my book, I don't
know of any on-demand lines with a timeout longer than 10 minutes
anyway.
But it will bring the line back *up*, to no useful
Mind you, this is only a problem because FreeBSD is to bloddy
stable: I logged into a customers server a few days a go, it had
been up for over a year, and had accumulated tons of ftpds from
WIN* machines which had gotten a vulcan nerve pinch or a different
IP#. (I'm sure windows NT servers
this is less and less of a problem because
if you lose your link on PPP
you are liable to get a differetn IP address on your redial.
for network outages in the middle it works though..
but I'd rather have a keepalive of 10 x 4 hour pings before failure..
(or something as long..)
It's really a
Mind you, this is only a problem because FreeBSD is to bloddy
stable: I logged into a customers server a few days a go, it had
been up for over a year, and had accumulated tons of ftpds from
WIN* machines which had gotten a vulcan nerve pinch or a different
IP#. (I'm sure windows NT servers
In message 19990601192912.68cc115...@hub.freebsd.org, Jonathan M. Bresler w
rites:
we should consult with hte tcp-impl mailing list and get their
take on the matter before we decide what to do here. the address is
tcp-i...@grc.nasa.gov.
I already did, but it is such a hot issue that they
this is less and less of a problem because
if you lose your link on PPP
you are liable to get a differetn IP address on your redial.
Not true. Only if you're using a dynamic IP address setup. Most
business connections have a static connection, so they'll end up with
the same IP address
In message 199906012011.paa16...@gungnir.fnal.gov, Matt Crawford writes:
... and keep dynamic lines up when they should otherwise have been
allowed to fall down.
[...]
The second argument falls on the same reasoning in my book, I don't
know of any on-demand lines with a timeout longer than 10
Why not just fix the application programs that really want timeouts but
don't implement them?
DS
Mind you, this is only a problem because FreeBSD is to bloddy
stable: I logged into a customers server a few days a go, it had
been up for over a year, and had accumulated tons
Saying that it should be an application function is bogus in my
book, since the problem is valid for all TCP users, and there are
clearly not any reason to duplicate the code in telnetd, ftpd,
talkd, c c.
But the problem is that every application uses TCP a little bit
differently,
That is a much more genuine concern than bandwidth. Applications should
decide for themselves whether or not to use keepalives.
-Kip
On Tue, 1 Jun 1999, Matthew Hunt wrote:
On Tue, Jun 01, 1999 at 12:40:34PM -0700, k...@lyris.com wrote:
declared dead.
On Tue, Jun 01, 1999 at 02:15:05PM -0600, Nate Williams wrote:
Can people live with a one week TCP keepalive as default ?
Compromise. I like it. One week is certainly adequate for me. If I
leave a link 'active' for longer than that w/out activity, I deserve to
lose the link
Surely that
how about a keepalive of 48 days.. the maximum a W95 machine can stay
alive... :-)
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Can people live with a one week TCP keepalive as default ?
Compromise. I like it. One week is certainly adequate for me. If I
leave a link 'active' for longer than that w/out activity, I deserve to
lose the link
Surely that violates POLA? That upsets people who have keepalive
In message 19990601212045.a13...@bell.maths.tcd.ie, David Malone writes:
On Tue, Jun 01, 1999 at 02:15:05PM -0600, Nate Williams wrote:
Can people live with a one week TCP keepalive as default ?
Compromise. I like it. One week is certainly adequate for me. If I
leave a link 'active' for
1 - 100 of 112 matches
Mail list logo
