www.mikrocontroller.net

Forum: PC Hard- und Software TCP/IP Frage,


Autor: Joe Lucky (lucky-joe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe Lucky (lucky-joe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe Lucky (lucky-joe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joe Lucky (lucky-joe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan L. (timpi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joe Lucky (lucky-joe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.