Hallo, ich konnte keine eindeutige Antwort darauf finden, wie lange eine IP/TCP Verbindung im kabelgebundenen LAN verlässlich offen bleiben kann? Konkret geht es um eine fixe kabelgebundenen LAN Verbindung zwischen zwei PCs die sich Daten senden. Da die Intervalle bis unter einer Sekunde sein können möchte ich die Verbindung dauerhaft offen lassen. Es kann aber auch sein, dass unter Umständen 2 Tage kein Daten ausgetauscht werden, in dem Fall würde ich dann einfach Intervallweise Fake-Daten senden um die Verbindung offen zu halten. Wie lang kann eine IP/TCP (im LAN!) dauerhaft offen bleiben? Was wäre ein sinnvolles Intervall für Fake-Daten zum "Keep Alive"? Viele Grüße
Asio schrieb: > Wie lang kann eine IP/TCP (im LAN!) dauerhaft offen bleiben? es gibt kein Limit > Was wäre ein sinnvolles Intervall für Fake-Daten zum "Keep Alive"? du musst das Rad nicht neu erfinden, aktivere einfach Keep-Alive für die Verbindung und gut ist. Aber das ist nur notwendig wenn z.b. noch ein NAT-Geräte dazwischen ist oder eine Hardware-Firewall
Flip B. schrieb: > schonmal an websocket gedacht? wozu diesen aufwand? Er will nur Daten austauschen, hier geht es nicht um Browser oder Webserver.
Peter II schrieb: > Asio schrieb: >> Wie lang kann eine IP/TCP (im LAN!) dauerhaft offen bleiben? > es gibt kein Limit > >> Was wäre ein sinnvolles Intervall für Fake-Daten zum "Keep Alive"? > du musst das Rad nicht neu erfinden, aktivere einfach Keep-Alive für die > Verbindung und gut ist. > > Aber das ist nur notwendig wenn z.b. noch ein NAT-Geräte dazwischen ist > oder eine Hardware-Firewall Das klingt super, ich mache das mit Boost Asio. Habe das eben gefunden: http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/reference/socket_base/keep_alive.html Wäre es damit schon schon getan und wird so wirklich die Verbindung automatisch offen gehalten?
Asio schrieb: > Wäre es damit schon schon getan und wird so wirklich die Verbindung > automatisch offen gehalten? es ist eigentlich überhaupt nicht notwendig, es gibt kein Limit. Das Keep alive braucht man erst wenn NAT dazwischen gemacht wird. Weil dort die Verbindungsliste ein Timeout hat. Bei normaler Verbindung mit Switchs, Routern ist es nicht notwendig.
Wo ist das Problem es einfach mal zu testen? mache ein Telnet/SSH zu den PC auf und lass es tagelang offen.
Peter II schrieb: > Das Keep alive braucht man erst wenn NAT dazwischen gemacht wird. Es hilft gerade bei langlaufenden Verbindungen ohne Datenübertragung früher zu erkennen wenn die Verbindung doch mal getrennt wird. Z.B. wenn mal ein PC rebootet wird oder irgendwer am Kabel wackelt.
Peter II schrieb: > Bei normaler Verbindung mit Switchs, Routern ist es nicht notwendig. Ausnahme: Router, die eine (z.B. PPP-)Verbindung nur bei Bedarf aufbauen. Die machen zwar oft auch NAT, da besteht aber kein notwendiger Zusammenhang.
Ja ich werde es einfach mal testen. Ich hatte gelesen das Betriebsysteme gewisse Timeouts haben wo inaktive Verbindungen/Sockets geschlossen werden daher die Fragen. Das Keep-Alive-Setting macht wahrscheinlich auch nur Serverseitig Sinn vermute ich mal.
guest schrieb: > Es hilft gerade bei langlaufenden Verbindungen ohne Datenübertragung > früher zu erkennen wenn die Verbindung doch mal getrennt wird. Z.B. wenn > mal ein PC rebootet wird oder irgendwer am Kabel wackelt. die Frage ist ob man da wissen muss. Meist reicht es wenn man Daten sendet, das dann eine Fehlermeldung kommt. Dann baut man halt die Verbindung neu auf.
Asio schrieb: > Das Keep-Alive-Setting macht wahrscheinlich auch nur Serverseitig Sinn > vermute ich mal. Kommt drauf an, was man damit erreichen will. Für den Server kann Keepalive sinnvoll sein, wenn er damit Ressourcen für längst nicht mehr vorhandene Clients freischaufeln kann, die verschwunden sind, ohne die TCP-Verbindung zu schließen. Falls der nächste Schritt einer lang offen gehaltenen Verbindung immer vom Client ausgehen muß, wird ein Server ohne Keepalive niemals bemerken, daß Clients verschwunden sind und irgendwann keine neuen Verbindungen mehr annehmen können, weil er das Limit an gleichzeitig offenen Sockets erreicht hat. Ist das Ziel aber (auch), eine abgebrochene Verbindung möglichst schnell neu aufzubauen, muß es (auch) auf dem Client benutzt werden.
Wenn der Datentranfer immer nur von einer Seite initiiert wird, warum solltest du dann die Verbindung offen halten? Ab einem gewissen Punkt erzeugst du ja mit den Keep-Alive Paketen mehr Traffic, als mit dem TCP handshake. Eine Strategie, wie du eine unterbrochene Verbindung neu aufbaust brauchst du sowieso, falls mal die Leitung unterbrochen wird. z.B. Neustart einer FritzBox nach Update.
Asio schrieb: > dass unter Umständen 2 Tage kein Daten ausgetauscht > werden, in dem Fall würde ich dann einfach Intervallweise Fake-Daten > senden um die Verbindung offen zu halten. Wozu, wenn es zwei Tage nichts zum Senden gibt dann mach die Verbindung zu. Alles andere heizt nur unnötig den Planeten auf. Deine Applikation muss so wie so damit klar kommen das mal einen Verbindung wegbricht. Sei es nun eine DSL Zwangstrennung oder ein Netzwerk Segment das gewartet werden muss. Eine Seriöse Netzwerk Anwendung steckt das weg und Baut eine neue Verbindung auf. Außer im Labor betrieb solltest du besser den Fall mit ein Planen das die Verbindung Weg geflogenen ist, das kommt selbst bei den Big Playern vor. Also Design deine Applikation besser so das die mit ein reconnect klar kommt.
Für Deine Anwendung macht UDP viel mehr Sinn, da brauchst Du Dich nicht um die Verbindung zu kümmern und die Intervalle in denen Du senden willst spielen auch keine Rolle.
Johnny B. schrieb: > Für Deine Anwendung macht UDP viel mehr Sinn, da brauchst Du Dich nicht > um die Verbindung zu kümmern und die Intervalle in denen Du senden > willst spielen auch keine Rolle. Wenn er aber will, das die Daten wirklich ankommen, macht UDP keinen sinn.
Asio schrieb: > Konkret geht es um eine fixe kabelgebundenen LAN Verbindung zwischen > zwei PCs die sich Daten senden. Da die Intervalle bis unter einer > Sekunde sein können Die eigentliche Frage ist doch wie lange darf die Latenz sein, sprich reicht es zum Verbindungsaufbau. Oder wenn die Latenz größer sein darf, dann könnte man ja auch Daten sammeln und erst senden wenn eine gewisse Menge aufgelaufen ist oder seit einer Zeit X gesammelt wird. Einfach die Verbindung auflassen klingt mir nach dem Versuch alles möglichst programmierfaul zu gestalten. Meist kriegt man dafür einen Bumerang zurück daß man dann ewig mit Problemen durch das schlechte Konzept kämpft.
Der Andere schrieb: > Einfach die Verbindung auflassen klingt mir nach dem Versuch alles > möglichst programmierfaul zu gestalten. Meist kriegt man dafür einen > Bumerang zurück daß man dann ewig mit Problemen durch das schlechte > Konzept kämpft. finde ich nicht. Warum sollte man sich den Aufwand machen immer eine neue Verbindung aufzubauen. Das man mit einer abgebrochenen Verbindung zurechtkommen muss ist klar. Eine offene Verbindung kostet keine CPU-Zeit, dagegen ist der Verbindungsaufbau aufwendig. Bei http wurde erst eingeführt das die Verbindung offen bleibt und nicht ständig geöffnet wird. Ich mache putty auch nicht zu, wenn ich nur einmal in der Stunde die Verbindung brauche.
Peter II schrieb: > Johnny B. schrieb: >> Für Deine Anwendung macht UDP viel mehr Sinn, da brauchst Du Dich nicht >> um die Verbindung zu kümmern und die Intervalle in denen Du senden >> willst spielen auch keine Rolle. > > Wenn er aber will, das die Daten wirklich ankommen, macht UDP keinen > sinn. UDP ist äusserst zuverlässig, normalerweise gehen da keine Daten verloren. Falls es kritisch ist, kann man in der übergeordneten Applikation ein kleines Handshake einbauen. z.B. ein Acknowledge vom Empfänger an den Sender. Das mit der ständig geöffneten TCP Verbindung ist ein Murks. Denn da gibt es keine Garantie, dass die Verbindung für ewige Zeit offen bleibt. Da muss man einen Mechanismus in seine Applikation einbauen, welche die Verbindung wieder herstellt, wenn sie mal getrennt wurde.
Johnny B. schrieb: > Das mit der ständig geöffneten TCP Verbindung ist ein Murks. Denn da > gibt es keine Garantie, dass die Verbindung für ewige Zeit offen bleibt. > Da muss man einen Mechanismus in seine Applikation einbauen, welche die > Verbindung wieder herstellt, wenn sie mal getrennt wurde. das man die Verbindung nach einen Fehler neu aufbauen ist klar. Aber immer noch besser als TCP über UDP neu zu erfinden.
TCP ist auch nur so lange zuverlässig, wie die Verbindung nicht durch äußere Einflüsse gestört wird. Wenn z.B. die DSL-Einwahl in die Zwangstrennung läuft oder sich ein WLAN-Client aus dem Empfangsbereich bewegt, können sich die Partner einer TCP-Verbindung, die dadurch unterbrochen wird, nicht sicher sein, ob ihre jeweils zuletzt gesendeten Daten noch angekommen sind oder nicht.
> UDP ist äusserst zuverlässig, normalerweise gehen da keine Daten > verloren. Tja, als ich im letzten Jahrtausend einem Cisco4000 mal eine neue Firmware verpasst habe, per TFTP und damit UDP, war das uebermittelte Firmwareimage kaputt. Warnungen gab es keine. Beteiligte Geraete: Genau 2, Notebook und Cisco4000. Weitere Geraete in diesem Netzwerk: keine UDP ist nicht zuverlaessig! Eine Applikation die UDP benutzt, muss die Integritaet der Daten sichern. Als Ausgleich wurde ich instant mit ausgiebigen Kenntnissen des Cisco-Bootroms belohnt.
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag #5166687: > Eine Applikation die UDP benutzt, muss die Integritaet der > Daten sichern. Das ist bei TCP nicht anders. Wie vorher schon geschrieben wurde, kann die Verbindung abbrechen und die gerade übermittelnden Daten gehen dann ebenfalls mit der Verbindung verloren. Für TCP muss man also ebenfalls noch in der Applikation was programmieren, damit man über eine längere Zeit (Stunden, Tage, Wochen, wie es hier verlangt wird) keinen Datenverlust hat. Für die Anwendung von Asio, wo Daten mal in Sekundenbruchteilen und mal nur alle paar Tage versendet werden, passt nun mal UDP wie die Faust aus Auge. Wenn man in das übergeordnete Protokoll noch einen Zähler und eine Prüfsumme einbaut, kann man sehr einfach auf der Empfängerseite korrupte und fehlende Daten erkennen und vom Sender neu anfordern. Das sind nur ein paar wenige Zeilen Code.
Johnny B. schrieb: > Wenn man in das übergeordnete Protokoll noch einen Zähler und eine > Prüfsumme einbaut, kann man sehr einfach auf der Empfängerseite korrupte > und fehlende Daten erkennen und vom Sender neu anfordern. Das sind nur > ein paar wenige Zeilen Code. und genau das macht TCP schon. Einfach eine Quittung über TCP versenden und gut ist. Dafür muss man sich dann nicht um falsche Reihenfolge und defekte Daten kümmern oder doppelte Packete.
(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag #5166687: > UDP ist nicht zuverlaessig! Das hängt wohl von der Implementierung ab: https://de.wikipedia.org/wiki/User_Datagram_Protocol Danach ist die Prüfsumme im Header optional. > Eine Applikation die UDP benutzt, muss die Integritaet der > Daten sichern. Ja, UDP ist ja per Definition nicht geschützt. Pakete können verloren gehen oder in anderer Reihenfolge beim Ziel ankommen. Im einfachsten Fall kann ja mit Quittungen arbeiten.
Bei der Diskussion um TCP oder UDP würde ich unbedingt auf die Spezifikation von dem jeweiligen Protokollen achten und nicht einfach ausprobieren. Testet man z.B. in lokalen Netzwerk, dann könnte UDP super funktionieren, weil kaum Pakete verloren gehen und die Reihenfolge vermutlich eingehalten wird. Dann will man aber plötzlich über ein paar Hops mehr durchs Internet uns es geht nicht mehr.
> Danach ist die Prüfsumme im Header optional.
Was optional ist, wird gern weggelassen und wird bei einem
unbedarften Kunden schonmal zu Panikattacken fuehren, wenn
er im Wireshark/Ethereal vermeintlich kaputte UDP-Pakete
sieht.
BTDT.
UDP ist fuer stateless Protokolle gedacht.
Das sind Protokolle die zu jedem Zeitpunkt unterbrochen
werden koennen und selbst ueber Mechanismen verfuegen
die Uebertragung/Verarbeitung exakt an diesem Punkt
wieder aufzunehmen, soweit dies noetig ist.
Wenn ein Sensor in einem lokalen LAN periodisch Messdaten
uebertraegt, wird niemand etwas gegen UDP haben.
Kaputte Frames werden normalerweise bereits vom Devicetreiber
aussortiert. Das was uebrig bleibt und plausibel ist,
kann Mann dann sicher verwenden.
Wird die Verbindung getrennt, fehlen dann einfach Daten.
Eine Retransmission ist aber u.U. nicht noetig, weil mit
alten Sensordaten einer Regelung z.B. auch nicht gedient ist.
Werden Daten/Dateien uebertragen, sorgt der ueber UDP liegende
Protokollmechanismus von z.B. NFS dafuer, dass die fehlenden
bzw. fehlerhaften Pakete erneut gesendet werden.
Ist NFS mit den Optionen sync und soft gemountet, kann
Mann durchaus waehrend eines Transfers mal das Netzwerkkabel
ziehen und dann nach einer Stunde wieder stecken...
Das ist dann wirklich zuverlaessig aber nicht der Verdienst
der UDP-Protokollschicht.
Peter II schrieb: > Johnny B. schrieb: >> Wenn man in das übergeordnete Protokoll noch einen Zähler und eine >> Prüfsumme einbaut, kann man sehr einfach auf der Empfängerseite korrupte >> und fehlende Daten erkennen und vom Sender neu anfordern. Das sind nur >> ein paar wenige Zeilen Code. > > und genau das macht TCP schon. Einfach eine Quittung über TCP versenden > und gut ist. Dafür muss man sich dann nicht um falsche Reihenfolge und > defekte Daten kümmern oder doppelte Packete. Wenn während des Datentransfers die TCP-Verbindung abbricht, dann sind die Daten verloren, denn TCP baut eine abgebrochene Verbindung nicht automatisch wieder auf. Und dass eine über Stunden und Tage offene TCP-Verbindung mal abbricht ist äusserst wahrscheinlich. Also hört bitte damit auf zu behaupten, dass die Verwendung von TCP automatisch alle Netzwerkprobleme automatisch löst.
Johnny B. schrieb: > Wenn während des Datentransfers die TCP-Verbindung abbricht, dann sind > die Daten verloren, denn TCP baut eine abgebrochene Verbindung nicht > automatisch wieder auf. richtig, niemand behauptet auch etwas anders > Und dass eine über Stunden und Tage offene > TCP-Verbindung mal abbricht ist äusserst wahrscheinlich. merkwürdig, bei mir bleiben sie wochenlang ohne Problem offen. Sogar über Internet und nicht nur im lokalem Netzt. Es gibt überhaupt keine Grund warum sie abrechen sollten. > Also hört bitte damit auf zu behaupten, dass die Verwendung von TCP > automatisch alle Netzwerkprobleme automatisch löst. wo habe ich das geschrieben?
Moin, wenn es sich bei deinen OS um vernünftige TCP-Implementierungen handelt, können die schon mal monatelang offenbleiben. Die Disconnects macht wenn, dann nur dein Server/Client. Hast du aber hunderte von Clients, kann es lustig werden, besonders beim ollen ws32. Auf jeden Fall cleanup-Handler für disconnects (Klassiker: broken pipe) einrichten. Wenn es robust UND latenzminimiert sein soll, fährst du am besten zweigleisig (UDP und TCP). TCP hängt unter ungünstigen Umständen lange oder ewig (bis ca. 30s vor Disconnect), je nach Bösartigkeit potentieller Störer im Netzwerk.
Peter II schrieb: > Johnny B. schrieb: >> Und dass eine über Stunden und Tage offene >> TCP-Verbindung mal abbricht ist äusserst wahrscheinlich. > merkwürdig, bei mir bleiben sie wochenlang ohne Problem offen. Sogar > über Internet und nicht nur im lokalem Netzt. Bei Deinem Netzwerk mag dies so sein. Aber ich implementiere Software meistens so, dass diese möglichst überall funktioniert und nicht nur bei einer bestimmten Konstellation. Dies würde ich auch jedem so empfehlen. Also auf dieses Beispiel hier im Thread bezogen, würde ich es so robust implementieren, dass es auch für Netzwerke die mit DHCP arbeiten funktioniert (z.B. ablaufende Lease-Time), mit Managed Switches (z.B. disconnect bei inaktivität), VPN, Computerreboots etc.
Johnny B. schrieb: > Bei Deinem Netzwerk mag dies so sein. Aber ich implementiere Software > meistens so, dass diese möglichst überall funktioniert und nicht nur bei > einer bestimmten Konstellation. was hat das eine mit dem andere zu tun? Selbstverständlich muss die Software damit klar kommen, das die Verbindung abbricht. > Dies würde ich auch jedem so empfehlen. wie schon oben mehrfach geschrieben, ist das selbstverständlich.
Asio schrieb: > Ja ich werde es einfach mal testen. Ich hatte gelesen das Betriebsysteme > gewisse Timeouts haben wo inaktive Verbindungen/Sockets geschlossen > werden Definiere "inaktiv"! Wenn du das im Sinne "es geht nix mehr drüber" definierst, dann stimmt es nicht. Definierst du das aber im Sinne "es geht nix mehr drüber, obwohl 1) lt. Verbindungsstatus was drübergehen sollte und 2) auch tatsächlich die Verbindung genutzt wurde (also etwas gesendet wurde und nun ein Antwort darauf erwartet wird), dann stimmt es. > Das Keep-Alive-Setting macht wahrscheinlich auch nur Serverseitig Sinn > vermute ich mal. Ob das überhaupt einen Sinn ergibt, hängt, wie von mehreren Leuten schon gesagt, von den Geräten ab, die die Pakete passieren müssen. Solange das nur einfache Switche sind, braucht man kein Keep-Alive. Und wenn man es braucht, ist es egal, auf welcher Seite der Verbindung es aktiv ist. Denn, wenn eine TCP-Verbindung erst einmal etabliert ist, sind ihre beiden Enden vollkommen gleichberechtigt. Beide sind dann gleichermaßen Client und Server. Es ist dann also Schwachsinn, von "serverseitig" zu sprechen.
c-hater schrieb: > Und wenn man es braucht, ist es egal, auf welcher Seite der Verbindung > es aktiv ist. Denn, wenn eine TCP-Verbindung erst einmal etabliert ist, > sind ihre beiden Enden vollkommen gleichberechtigt. Beide sind dann > gleichermaßen Client und Server. Es ist dann also Schwachsinn, von > "serverseitig" zu sprechen. Der Server hat aber einen Grund es zu aktivieren. Denn wenn der Client wegen seinem Internet Zugang eine neue IP Bekommt, dann gibt es eine offene Verbindung die NIE geschlossen wird. Der Client bekommt beim nächsten senden einen Fehler und muss die Verbindung neu aufbauen.
@Peter II (Gast) >Der Server hat aber einen Grund es zu aktivieren. Denn wenn der Client >wegen seinem Internet Zugang eine neue IP Bekommt, dann gibt es eine >offene Verbindung die NIE geschlossen wird. Soweit ich weis, wird der Server und Client aber bei solch bewußten Trennungen davon informiert (von Routern, Modems, oder sonst was, was an der Trennung beteiligt ist). Besser gesagt, der TCPIP-Stack. Dem Serverprozess, wenn im Listen-Status (wenn er grad nix zu tun hat), oder dann bei der nächsten Aktion gegen den Stack, wird dies dann vom Stack mit (ich glaube) econnreset oder irgendsowas wie eclosedbypeer mitgeteilt. Der Stack auf dem Client müsste daselbe von der Fritzbox (z.B.) mitgeteilt bekommen, was den Clientprozess dann bei der nächsten Aktion (oder wenn er gerade auf den Server wartet) zur Aufgabe bewegen sollte. Keepalive ist eigentlich nur nötig, um festzustellen, ob sich die Gegenseite unsauber aus dem Verkehr gezogen hat, ohne die Session sauber zu beenden (lassen). Und soweit ich weis, machen gewisse Router, Firewalls auch die Connection zu, wenn da ewig keine Datenpakete mehr drüber gehen. Dann wirkt keepalive Wunder, durch Vortäuschen reger Geschäftstätigkeit auf der Leitung.
> Soweit ich weis, wird der Server und Client aber bei solch > bewußten Trennungen davon informiert (von Routern, Modems, > oder sonst was, was an der Trennung beteiligt ist). Genau das passiert eben nicht! Erst, wenn versucht wird, Daten an die Gegenseite zu senden, bekommt man (evtl erst nach längeren Time-outs) entsprechende Benachrichtigungen/Fehlerrückmeldungen. Eine Seite, die ausschließlich auf Anforderung Daten sendet, bekommt von einer Trennung nichts mit - nur, dass keine Anforderungen mehr kommen ...
> Und soweit ich weis, machen gewisse Router, Firewalls auch die > Connection zu, wenn da ewig keine Datenpakete mehr drüber gehen. > Dann wirkt keepalive Wunder, durch Vortäuschen reger > Geschäftstätigkeit auf der Leitung. Machen alle mit Connection-Tracking, sonst würde denen irgendwann der Speicher überlaufen. Btw, das TCP-Keep-Alive-Intervall bewegt die üblicherweise im 2h-Bereich - eben keine "rege Geschäftstätigkeit", zu lang für viele Connection-Tracker.
Jens G. schrieb: > Soweit ich weis, wird der Server und Client aber bei solch bewußten > Trennungen davon informiert (von Routern, Modems, oder sonst was, was an > der Trennung beteiligt ist). nein, TCP wurde so entworfen, das nur die Endgeräte die Verbindung kennen. Router leitet nur Pakete weiter und kümmern sich nicht um so etwas wie Verbindungen. Nur bei NAT wird das Prinzip verletzt, weil es dafür keine alternative gibt. Aber auch dort wie niemand informiert.
asdfasd schrieb: > Btw, das TCP-Keep-Alive-Intervall bewegt die üblicherweise im 2h-Bereich Standardeinstellung des Timeouts vom Apache 2.4 ist 5 Minuten. Noch weiter runter haben sie sich nicht getraut. Bei Webservern sind ungenutze Dauerverbindungen allerdings auch nicht gerade üblich.
:
Bearbeitet durch User
A. K. schrieb: > Standardeinstellung des Timeouts vom Apache 2.4 ist 5 Minuten. das hat doch nichts mit Keep-Alive zu tun. Selbst wenn ein Keep-Alive-Packet übertragen wird sind das doch keine Nutzdaten und der Timeout in der Anwendung schlägt trotzdem zu.
asdfasd schrieb: >> Soweit ich weis, wird der Server und Client aber bei solch >> bewußten Trennungen davon informiert (von Routern, Modems, >> oder sonst was, was an der Trennung beteiligt ist). > > Genau das passiert eben nicht! Mit einer Ausnahme. Wenn das Ethernetkabel zu dem entsprechenden PC gekappt wird kann die Netzwerkkarte das erkennen. Und wenn die Treiber und der TCP-Stack mitspielen und der Programmieren kein Volldepp ist kann auch die Software das mitbekommen. Ansonsten hast Du natürlich völlig Recht.
guest schrieb: > Mit einer Ausnahme. Wenn das Ethernetkabel zu dem entsprechenden PC > gekappt wird kann die Netzwerkkarte das erkennen. Und wenn die Treiber > und der TCP-Stack mitspielen und der Programmieren kein Volldepp ist > kann auch die Software das mitbekommen. Ansonsten hast Du natürlich > völlig Recht. die Frage ist ob das überhaupt sinnvoll ist. Windows macht es so, es werden alle Sockets geschlossen wenn der Link weg ist. Linux macht es nicht. Wobei ich mir nicht sicher bin, was schöner ist. Warum sollte alle Verbindungen getrennt werden nur weil man mal kurz den Stecker gezogen hat? Wenn man zwischen 2 Switchs den Stecker kurz zieht, dann werden auch keine Verbindungen getrennt.
guest schrieb: > it einer Ausnahme. Wenn das Ethernetkabel zu dem entsprechenden PC > gekappt wird kann die Netzwerkkarte das erkennen. Aber nur wenn das Kabel an diesem Gerät entfernt wird. Wenn das in einem Segement hinter einem Switch oder einem Medienkonverter passiert bekommst du nix mitgeteilt. Es reicht nicht sich darauf zu verlassen.
Peter II schrieb: >> Standardeinstellung des Timeouts vom Apache 2.4 ist 5 Minuten. > > das hat doch nichts mit Keep-Alive zu tun. Ob es direkt mit der Socket-Option zu tun hat weiss ich nicht. Allerdings verwendet Apache diesen Parameter für diverse Timeouts und hält nicht geschlossene Verbindungen entsprechend dieser Zeit offen. Die oben erwähnten 2 Stunden wären bei öfter genutzten Webserver fatal. https://httpd.apache.org/docs/2.4/en/mod/core.html#timeout
:
Bearbeitet durch User
> Windows macht es so, es werden alle Sockets geschlossen wenn der > Link weg ist. Bist du sicher??? Das wäre ein ziemlich bescheuertes und sinnloses Verhalten.
asdfasd schrieb: > Bist du sicher??? ja (kann man aber ändern, wenn man es will) > Das wäre ein ziemlich bescheuertes und sinnloses Verhalten. oder Konsequente Umsetzung des OSI Modells. eine Trennung der unteren Schichten wird an die höheren Schichten übergeben.
>>> Windows macht es so, es werden alle Sockets geschlossen wenn der >>> Link weg ist. >> >> Das wäre ein ziemlich bescheuertes und sinnloses Verhalten. > > oder Konsequente Umsetzung des OSI Modells. eine Trennung der unteren > Schichten wird an die höheren Schichten übergeben. Aber warum sollte ein temporäres Problem auf dem Link-Layer an allen Sicherungslayern vorbei zu einer Terminierung auf dem Applicationlayer führen? IP hätte evtl ne alternative Route gesucht, TCP ne Retransmission durchgeführt, etc.
... mir schwant was: die Anwender waren zu ungeduldig, die Timeouts abzuwarten :-(
asdfasd schrieb: > IP hätte evtl ne alternative Route gesucht geht nicht, weil die IP ja ans Interface gebunden ist und das ist ja Down. Es geht nicht um Router sondern um ein Endgerät.
>> IP hätte evtl ne alternative Route gesucht > > geht nicht, weil die IP ja ans Interface gebunden ist und das ist ja > Down. Spielt doch erstmal keine Rolle, solange noch eine Route für die "Ziel-IP" existiert. Ob die Antworten ankommen, liegt dann am Router.
asdfasd schrieb: > Spielt doch erstmal keine Rolle, solange noch eine Route für die > "Ziel-IP" existiert. Ob die Antworten ankommen, liegt dann am Router. nein, es würden aber keine Antworten mehr akzeptiert, denn die (Absender)IP ist nicht mehr vorhanden. Das ist wie bei Linux. Wenn du if down machst, dann ist auch schluss mit den IPs auf dem Interface. Windows macht das "Down" halt sobald der Link weg ist.
> Das ist wie bei Linux. Wenn du if down machst, dann ist auch schluss mit > den IPs auf dem Interface. Windows macht das "Down" halt sobald der Link > weg ist. Gerade mal kurz getestet: bei link-down bleibt das Interface up - bekannt. Bei nem ifconfig down bleiben die Sockets erhalten und sobald das Interface wieder up ist, geht's weiter. Auch wenn das Interface down ist, bleibt die Adresse des Interfaces weiter bekannt - ein ping z.B. reagiert, connects gehen. Ich gehe mal davon aus, daß Pakete für diese IP auch weiterhin angenommen werden, wenn sie über ein anderes Interface reinkämen - das zu Testen ist mir jetzt aber zu aufwendig ;-)
asdfasd schrieb: > Auch wenn das Interface down ist, bleibt die Adresse des Interfaces > weiter bekannt - ein ping z.B. reagiert, connects gehen. dieses Verhalten ist aber auch nicht gerade schlau.
Das IP-Protokoll ist darauf ausgelegt, temporäre Netzausfälle zu überstehen. Warum sollte das ausgerechnet für den lokalen Link nicht gelten?
R. M. schrieb: > Warum sollte das ausgerechnet für den lokalen Link nicht gelten? Wie schon oben von jemand geschrieben, ist es durchaus im sinne des Anwenders. Warum mehre Sekunden auf einen Timeout warten weil kein Link vorhanden ist? Wenn man will, kann man diese verhalten abschalten.
Peter II schrieb: > Warum mehre Sekunden auf einen Timeout warten weil kein Link > vorhanden ist? Warum eine TCP-Verbindung abbrechen, nur weil der Link eben mal für ein paar Sekunden weg ist? > Wenn man will, kann man diese verhalten abschalten. Ich benutze lieber ein OS, das es von Hause aus richtig macht. ;)
:
Bearbeitet durch User
R. M. schrieb: > Warum eine TCP-Verbindung abbrechen, nur weil der Link eben mal für ein > paar Sekunden weg ist? Es gibt für beide Entscheidungen Gründe, ich habe mir das doch nicht ausgedacht. wenn es jemand stört kann er es ja umstellen.
>> Auch wenn das Interface down ist, bleibt die Adresse des Interfaces >> weiter bekannt - ein ping z.B. reagiert, connects gehen. > > dieses Verhalten ist aber auch nicht gerade schlau. Na ja, du kannst ja auch dem System die IP-Adresse wegnehmen, oder sie einem anderen Interface zuweisen. Die Kopplung zwischen IP-Adresse und Interface ist einfach lockerer[1]; das Interface spielt nicht mehr die zentrale Rolle sondern ist nur ein Peripheriegerät für höhere Protokollschichten. Diese Entkopplung ist wohl für Linux' komplexere Features notwendig gewesen. [1] ifconfig(8) gaukelt einem noch die alte Sichtweise vor. Bei ip(8) sieht man die Trennung deutlicher ("ip link" vs "ip addr")
asdfasd schrieb: >> Soweit ich weis, wird der Server und Client aber bei solch >> bewußten Trennungen davon informiert (von Routern, Modems, >> oder sonst was, was an der Trennung beteiligt ist). > > Genau das passiert eben nicht! Erst, wenn versucht wird, Daten an die > Gegenseite zu senden, bekommt man (evtl erst nach längeren Time-outs) > entsprechende Benachrichtigungen/Fehlerrückmeldungen. Eine Seite, die > ausschließlich auf Anforderung Daten sendet, bekommt von einer Trennung > nichts mit - nur, dass keine Anforderungen mehr kommen ... Ganz genau so sieht es auf der Ebene von TCP aus. All der ganze Bullshit mit Inaktivitäts-Timeouts, der hier verzählt wurde, handelt schlicht auf höheren Protokollebenen...
c-hater schrieb: > All der ganze Bullshit mit Inaktivitäts-Timeouts, der hier verzählt > wurde, handelt schlicht auf höheren Protokollebenen... Da der Threadersteller eine konkrete Applikation zu implementieren im Sinn hat, muss er diese "höheren Protokollebenen" aber eben berücksichtigen. Daher ist Deine Aussage in etwa so nutzlos wie ein geladenes Neutron.
Johnny B. schrieb: > c-hater schrieb: >> All der ganze Bullshit mit Inaktivitäts-Timeouts, der hier verzählt >> wurde, handelt schlicht auf höheren Protokollebenen... > > Da der Threadersteller eine konkrete Applikation zu implementieren im > Sinn hat, muss er diese "höheren Protokollebenen" aber eben > berücksichtigen. Daher ist Deine Aussage in etwa so nutzlos wie ein > geladenes Neutron. Wer lesen kann, ist ganz klar im Vorteil. Die Frage des TO war: > ich konnte keine eindeutige Antwort darauf finden, wie lange eine IP/TCP > Verbindung im kabelgebundenen LAN verlässlich offen bleiben kann? Und die einzig richtige Anwort darauf ist nunmal: unendlich, es sei denn, irgendein höheres Protokoll will es anders... Was nun diese höheren Protokolle betrifft, kann man genau so lange keine sinnvollen Aussagen machen, so lange sie nicht BEKANNT sind. Der TO hat sich nicht dazu geäußert, also ist alles zu diesem Thema nur reine Spekulation, also vollkommen nutzloser Bullshit.
c-hater schrieb: >> ich konnte keine eindeutige Antwort darauf finden, wie lange eine IP/TCP >> Verbindung im kabelgebundenen LAN verlässlich offen bleiben kann? > > Und die einzig richtige Anwort darauf ist nunmal: unendlich, es sei > denn, irgendein höheres Protokoll will es anders... Unendlich ist in der Theorie richtig, aber der TO macht keine Doktorarbeit, sondern eine reale Anwendung und da muss man nun mal damit umgehen können, dass die Verbindung mal getrennt werden kann, ob es Dir nun passt oder nicht.
Besten Dank für die vielen interessanten Beiträge! Ich werde auf jeden Fall auf Nummer sicher gehen: - Verbindungswiederherstellung bei Verbindungsabbruch. - Client bekommt immer Bestätigung von Server ob Daten angekommen sind. - Wenn Client keine Daten senden kann speichert er diese und übermittelt sie wenn Verbindung wieder besteht. Grüße
Peter II schrieb: > R. M. schrieb: >> Warum sollte das ausgerechnet für den lokalen Link nicht gelten? > > Wie schon oben von jemand geschrieben, ist es durchaus im sinne des > Anwenders. Warum mehre Sekunden auf einen Timeout warten weil kein Link > vorhanden ist? Weil der Link nicht zwingend für immer und ewig weg sein muss. Ein Timeout ist dafür da, dass nicht gleich sofort alles weg ist, wenn die Verbindung kurzzeitig gestört ist. Und wie oben schon steht: >> Warum sollte das ausgerechnet für den lokalen Link nicht gelten?
Peter II schrieb: > Flip B. schrieb: >> schonmal an websocket gedacht? > > wozu diesen aufwand? Er will nur Daten austauschen, hier geht es nicht > um Browser oder Webserver. weil websockets nicht nur für browser oder webserver gedacht ist websockets an sich sind hier schon eine recht gute wahl weil man durch diesen kanal wirklich recht einfach daten hin und her senden kann ohne auf die verbindung selbst zu achten. zumal websocket selbst ein PING/PONG mechanismuss hat
4328970765432459780876543 schrieb: > websockets an sich sind hier schon eine recht gute wahl > weil man durch diesen kanal wirklich recht einfach daten hin und her > senden kann ohne auf die verbindung selbst zu achten. > > zumal websocket selbst ein PING/PONG mechanismuss hat schon der Overhead bei verbindungsaufbau ist sinnlos und unnötig. dann läuft das ja selber noch über HTTP. Dann könnte man gleich noch XML darüber stülpen - resoucen kosten ja kein Geld. über TCP kann man genauso einfach Datenaustauschen, nur halt aus Javascript nicht. Deswegen ist websockets für Webclients das richtige, aber nicht wenn man nicht mit WEB am hut hat.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.