:>> 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 d
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:
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.
>
>> 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 Tue, Jun 08, 1999 at 11:23:26AM -0700, Matthew Dillon
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 went down,
> I wouldn'
:} 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 06:07:23AM -0700, Don Lewis
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 storm yesterday a
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:
} > < said:
} >
} > > FWIW, I think only a fool would want a computer to NOT drop dead
connections.
} > > Any &quo
"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 connecti
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 ``kee
:
: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
> 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 mor
Joel Ray Holveck 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 issue, but i
>> 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 wh
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 * UNIX is a lever for the
http://www.pobox.com/~mph/
> 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-
> :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 ext
From: Matthew Dillon
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> There are
: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 righ
:
:> 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 c
:<
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 no keepalives are scheduled for then!)
:
:> But remember th
:> 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, i
:>
:> 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
:> 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
>> 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 reconnect
> 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 t
> 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
--
J
> 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.
No
> 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 late
<
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 no keepalives are scheduled for then!)
> But remember that the i
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.
Garrett Wollman scribbled this message on Jun 5:
> <
> 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 ap
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 hav
On Sat, 5 Jun 1999, Garrett Wollman wrote:
> <
> 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,
<
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 is possible for perfectly
legitimate connections to get shot down a
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 e
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_ __ ___ | _ ) __| \
: 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 noth
> "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)
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:
> =+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
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-
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
"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
> 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
keepalive
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 whom
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 t
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 ins
: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 becom
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
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 pro
> 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
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
:
: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,
>> 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 problemati
: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
: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 wo
"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.
No offense, but that is the most ludicrous assertion I've heard since
Slobodan Milosevic
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
> 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 s
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
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 K
>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 corre
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
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 occassiona
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
> "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 discu
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
In message <199906041621.maa11...@khavrinen.lcs.mit.edu>, Garrett Wollman
writes:
>< 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 int
> 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, w
< 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 the inventors of TCP and he
tells you what an dolt you appear to be...
-GAWollma
: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" p
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
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
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 "unsubscri
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
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 *.demon.
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 thi
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
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 to their web
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 connectio
According to Matthew Hunt:
> I'm thinking of long-lived connections like telnet and ssh; if you're
FWIW ssh has been using keelalives for a long time by default...
KeepAlive
Specifies whether the system should send keepalive
messages to the other side. If t
Poul-Henning Kamp wrote:
>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.
I thi
:...
Sheesh, talk about a topic to generate noise!
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.
The reason is simple: Without keepalives you can end up w
> > maybe we should fix our SERVER apps..
> > e.g. telnetd, sshd, etc. to have 1 week timeouts
>
> IIRC, it is not possible to specify how long the keepalive interval
> should be, using the socket interface. Do you suggest we add a new
> interface not present in other Unix implementations, or tha
Poul-Henning Kamp writes:
> 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
If this customer is using wu-ftpd, it's very possible that you saw
daemons
This does make sense. I do some work on a mail server and I don't use
keepalives because 2 hours is _too_much_ time to be wasting a descriptor.
I periodically check how long a connection has been open and if it exceeds
a certain amount I close the connection.
-Kip
Yes, exactly, everybody wants something different. That's why you don't
want to enforce a new policy in the kernel. Let each app choose the policy
that makes the most sense for it, either with or without command line
options or whatnot.
But an application that is not happy with th
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 periods,
and have no parti
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?)
DS
> On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:
>
> > maybe we should fix our SERVER apps..
> > e.g. telnetd, sshd, etc.
On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:
> maybe we should fix our SERVER apps..
> e.g. telnetd, sshd, etc. to have 1 week timeouts
IIRC, it is not possible to specify how long the keepalive interval
should be, using the socket interface. Do you suggest we add a new
inter
maybe we should fix our SERVER apps..
e.g. telnetd, sshd, etc. to have 1 week timeouts
On Tue, 1 Jun 1999, David Schwartz wrote:
>
> Why not just fix the application programs that really want timeouts but
> don't implement them?
>
> DS
>
> > Mind you, this is only a problem becaus
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.
-Kip
On Tue, 1 Jun 1999, Julian Elischer wrote:
> how about a keepalive of 48 days.. the maximum a W95
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 'ac
> > > 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 k
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
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 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 de
> 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
differentl
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
1 - 100 of 113 matches
Mail list logo
