Hallo Gemeinde, ich habe eine TCP/IP-Frage, ich hoffe es kennt sich jemand damit aus? Ich habe zwei Systeme (Steuerung (Ctrl) und Proxy (Pr)) und welche miteiander via TCP/IP(Eth) miteinander kommunizieren. Die Socket-Implementierung ist etwas eigenwillig aber macht keine Probleme bis ich den Proxy reboote. Zwischen dem Ctrl und dem Proxy sitzt noch ein Linux mit NAT/Masqerade zur Adresstranslation Der Ctrl (Thread 1) connected den Proxy auf Port 15002 und die Verbindung steht dann und alles läuft prima. Nach dem Reboot des Proxy versucht der Ctrl (Thread 2) den Proxy erneut auf Port 15002 zu connecten, was auch klappt. Was passiert hier nun mit der ersten Verbindung, wie sollte dieser Konflikt von TCP/IP erkannt und gelöst werden? Vermutlich habe ich da was nicht ganz verstanden aber vielleicht könnt ihr mir hier ja weiterhelfen? t.i.a Joe
Joe Lucky schrieb: > Was passiert hier nun mit > der ersten Verbindung, wie sollte dieser Konflikt von TCP/IP erkannt und > gelöst werden? was meinst du damit? Der Proxy hat doch keine 1.Verbindung mehr wennn er rebootet wird.
Peter schrieb: > Joe Lucky schrieb: >> Was passiert hier nun mit >> der ersten Verbindung, wie sollte dieser Konflikt von TCP/IP erkannt und >> gelöst werden? > was meinst du damit? Der Proxy hat doch keine 1.Verbindung mehr wennn er > rebootet wird. Ja das stimmt wohl, hatte ich mir zumindest auch gedacht, dennoch versucht der 1. Thread noch auf dem 1. Socket zu schreiben und der lässt sich nicht mehr schliessen. Die Frage wäre eigentlich wie die Verbindung im TCP/IP Stack identifiziert wird, nur durch ADresse und Port oder gibt es da sowas wie einen Connection-Identifier?
Joe Lucky schrieb: >> was meinst du damit? Der Proxy hat doch keine 1.Verbindung mehr wennn er >> rebootet wird. Der nicht, aber vielleicht hat "Ctrl" das nicht mitbekommen, falls der Proxy vor dem Reboot die Verbindung nicht ordnungsgemäß geschlossen hat. > Ja das stimmt wohl, hatte ich mir zumindest auch gedacht, dennoch > versucht der 1. Thread noch auf dem 1. Socket zu schreiben und der lässt > sich nicht mehr schliessen. Die Frage wäre eigentlich wie die Verbindung > im TCP/IP Stack identifiziert wird, nur durch ADresse und Port oder gibt > es da sowas wie einen Connection-Identifier? Nein. Die Verbindung wird ausschließlich über IP und Port beider Teilnehmer identifiziert.
Rolf Magnus schrieb: > Joe Lucky schrieb: >>> was meinst du damit? Der Proxy hat doch keine 1.Verbindung mehr wennn er >>> rebootet wird. > > Der nicht, aber vielleicht hat "Ctrl" das nicht mitbekommen, falls der > Proxy vor dem Reboot die Verbindung nicht ordnungsgemäß geschlossen hat. > ja genau das vermute ich auch aber wieso sollte der Proxy denn seinen Socket schliessen wenn er rebootet (OK, ich meinte ausgeschaltet)? Wie bekommt denn der "Ctrl" mit, dass die Gegenseite nicht mehr vorhanden ist? > Nein. Die Verbindung wird ausschließlich über IP und Port beider > Teilnehmer identifiziert. OK, war mir auch so aber ich war eben nicht ganz sicher
Hallo Joe, ist das eine theoretische Frage oder ein praktisches Problem? Wenn praktisches Problem dann versuch bitte mal genauer zu beschreiben, was vorher geht und hinterher nicht mehr - und woran Du fest machst, dass das Problem auch am PR liegen kann. Grüsse Michael
Michael schrieb: > Hallo Joe, > > ist das eine theoretische Frage oder ein praktisches Problem? > Wenn praktisches Problem dann versuch bitte mal genauer zu beschreiben, > was vorher geht und hinterher nicht mehr - und woran Du fest machst, > dass das Problem auch am PR liegen kann. > Hallo Michael, es kann nicht am Proxy liegen, denn den schalte ich ja aus und wieder ein und es ist ein praktisches Problem welches bei mir tatsächlich auftritt, es zu beschreiben ist auch nicht ganz so einfach da ich weit ausholen müsste und ich ja auch schon einiges analysiert habe. > Grüsse > Michael dennoch werde ich mal versuchen es vielleicht etwas genauer zu beschreiben, kann aber etwas dauern danke Joe
Hallo Joe, Joe Lucky schrieb: > Der Ctrl (Thread 1) connected den Proxy auf Port 15002 und die > Verbindung steht dann und alles läuft prima. > Nach dem Reboot des Proxy versucht der Ctrl (Thread 2) den Proxy erneut > auf Port 15002 zu connecten, was auch klappt. Was passiert hier nun mit > der ersten Verbindung, wie sollte dieser Konflikt von TCP/IP erkannt und > gelöst werden? Wird der Proxy hart ausgeschaltet? Wenn ja, dann: Wenn Ctrl (Thread 1) nach dem Proxy-Reboot erneut versucht etwas zu senden (und wirklich erst zu diesem Zeitpunkt), dann sollte vom Proxy ein TCP-RST kommen, denn der kennt ja die Verbindung (charakterisiert durch Quell-IP, Ziel-IP, Quell-Port und Ziel-Port) nicht mehr. Woraufhin Ctrl (Thread 1) erkennt, dass die Verbindung abgebrochen ist. Solange jedoch nichts gesendet werden soll geht Ctrl (Thread 1) davon aus, dass die Verbindung besteht. Ein Schließen des Client-Sockets sollte genau so funktionieren. Auf das FIN des Clients antwortet der Proxy mit einem RST. Warum sollte er auch eine aus seiner Sicht nicht mehr bestehende Verbindung beenden. Wenn der Proxy jedoch 'sauber' beendet wird, dann sollte er vor dem Reboot auch die TCP-Verbindung beenden (und auch eine gewisse Zeit warten, bis die Gegenseite das bestätigt hat) Was antwortet denn der Proxy auf das Paket von Ctrl (Thread 1) nach dem Reboot? Kommt das überhaupt beim Proxy an? Und, kann es sein, dass das Problem durch eine fehlerhafte Addresstranslation verursacht wird (also fehlerhaft für den beschriebenen Fall, sonst scheint es ja zu klappen)? timpi.
erstmal vielen Dank für die zahlreichen und sehr hilfreichen Antworten, ich werde versuchen mir das Ganze nochmals anzusschauen und zu verstehen was genau passiert. Danke und Grüße Joe
Was ich machen würde, wäre: 1. Client und Server als Simulation am PC laufen lassen Das ist einfacher zu verstehen und zu debuggen, z.B. hat man Programme wie netstat zuverlässig zur Verfügung 2. Wenn das klappt, dann erst den Simulationsclient durch den Controller ersetzen und ordentlich zum Laufen bringen (gegen den Server auf dem PC) 3. Dann entsprechend den Server auf einem anderen MC gegen den Client am PC 4. Client und Server zusammenklemmen (MC zu MC) Ansonsten stochert man doch nur im Morast und weiß nicht, wo man mit Fehlersuche beginnen soll.
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.