[LUGA] Mit freundlicher Unterstützung von:
OCG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bezeichnung "Keep-Alive" (was: [luga] iptables-Timeouts)



"Peter J. Holzer" <hjp-luga2@hjp.at> wrote:
 |On 2015-06-18 16:44:13 +0200, Peter J. Holzer wrote:
 |> On 2015-06-17 22:10:06 +0200, Steffen Nurpmeso wrote:
 |>> und Keepalive nun denn testet, ob die Verbindung noch besteht, um z.
 |>> B. sinnlose Ressourcenverschwendung auf der lokalen Box zu vermeiden, 
 |> 
 |> Das ist richtig. 
 |> 
 |>> es also «falsch» benannt ist,
 |> 
 |> Das könnte man so sehen, da der eigentliche Zweck nicht ist, die
 |> Verbindung am Leben zu erhalten, sondern im Gegenteil, tote Verbindungen
 |> zu erkennen. "Heartbeat" wäre heute wohl ein üblicherer Ausdruck für
 |> diese Funktionalität.
 |> 
 |> Ich weiß nicht, wann und und von wem diese Bezeichnung geprägt wurde. In
 |> RFC 1122 (Oktober 1989) wird sie verwendet, aber offenbar war das damals
 |> schon recht üblich.

Im originalen «INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL
SPECIFICATION», RFC 791 steht

  The internet protocol uses four key mechanisms in providing its
  service:  Type of Service, Time to Live, Options, and Header
  Checksum.

Im originalen TCP RFC 793 geht es (abgesehen von der TTL) noch um
Timeouts, aber sowohl die eine, als auch die anderen betreffen
einzig Aktionen.

 |In RFC 1001 (1987) wird ebenfals bereits darauf verwiesen, dass viele
 |TCP-Implementationen dieses Feature haben.

Aber die Notwendigkeit scheint wohl frühzeitig erkannt worden zu
sein.  In dem von dir angeführten RFC 1122 wird es voll behandelt.

 |Der Begriff wird in zwei früheren RFCs (RFC 891 (1983) und RFC 969
 |(1985)) im Zusammenhang mit anderen Protokollen verwendet. In beiden

Ich glaube ich hab's: in RFC 816 «FAULT ISOLATION AND RECOVERY»
von David D. Clark, MIT, Juli 1982 findet sich:

    But  the  host  end  of  the connection,  having  nothing  to
    send, will not discover anything wrong, and will remain waiting
    forever.  In some systems there is no way for  a user  in
    a  different  process  to  destroy or take over such a hanging
    process, so there is no way to recover.

    One solution to this would be to have the host server telnet
    query the  user  end now and then, to see if it is still up.
    (Telnet does not have an explicit query  feature,  but  the
    host  could negotiate  some unimportant   option,   which
    should   produce   either agreement  or disagreement in
    return.)

Das sieht jetzt daneben aus, aber aus den Gedankengängen in diesem
RFC scheinen sich allgemein akzeptierte Lösungen entwickelt zu
haben.

 |Fällen scheint hier das Paket tatsächlich die Funktion zu haben, die
 |Verbindung am Leben zu halten. Hier die Beschreibung auf RFC 969:
 |
 ||     The solution to the above two problems is the use of a death timer
 ||     and a keepalive packet for both the sending and receiving NETBLTs.
 ||     As soon as the connection is opened, each end sets a death timer;
 ||     this timer is reset every time a packet is received.  When a
 ||     NETBLT's death timer at one end expires, it can assume the other
 ||     end has died and can close the connection.
 |
 |Ich halte es für wahrscheinlich, dass die Bezeichnung übernommen wurde,
 |obwohl die Funktion und Implementation in TCP etwas anders ist - der
 |Zweck war ja der gleiche.

Absolut.

--steffen



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Juni 2015