Ich stehe gerade auf dem Schlauch... ich brauche eine 100%ig zuverlässige TCP/IP Kommunikation. Also:
- Der Sender (Client) muss 100%ig zuverlässig wissen, ob der Empfänger (Server) die Nachricht erhalten hat
- Der Empfänger (Server) muss 100%ig zuverlässig wissen, dass der Sender (Client) erfahren hat, dass der Empfänger die Nachricht erhalten hat

Irgendwie beisst sich da Gerade der Hund in den Schwanz... ich finde so auf die schnelle keine Lösung dafür...

Weiss jemand Rat? Hat jemand sowas schon mal gemacht?

PS: Mir würde es ausreichen, wenn man für jede Nachricht eine neue Verbindung zwischen CLient und Server aufbaut; das ich für mich als Beispiel ok.

PS: Mir würde es ausreichen, wenn man für jede Nachricht eine neue Verbindung zwischen CLient und Server aufbaut; das ich für mich als Beispiel ok.

dann haste es doch. für sowas ist TCP ja da. sender baut verbindung auf, sendet seine nachricht, der empfänger macht als quittierung die verbindung wieder zu. sobald irgendwelche anomalien auftreten (z.b. verbindung wird durch RST statt durch FIN-FIN geschlossen) wissen beide, das etwas nicht geklappt hat. der empfänger schmeisst im fehlerfall die message weg und der sender versucht's nochmal.

Quelle sendet Datenpakete am Empfänger
der Empfänger quitiert das der Quelle, damit weiss die Quelle, dass die Pakete gesendet würde. Reicht das nicht

Ist das "zuverlässig"?

Nehmen wir mal an:
- Quelle sendet Daten an Empfänger (send = ok)
- Empfänger liest diese und sender Quittung (send = ok)

Leider war jetzt zwischen dem Empfangen der Daten und dem Senden z.B. Auslastungsbeding eine "größere" zeit dazwischen (oder weil das Netzwerk so viele Störungen hat, was aktuell eigentlich mein Hauptproblem/ursache ist); nehemn wir also mal an 2 Sekunden.
Auf der Empfängerseite habe ich beim "recv" als Timeout auch 2 Sekunden angegeben!!!!
So was passieren kann ist folgendes:

- Der ursprüngliche Empfänger sendet die Quittung und diese wir dauch mittels TCP korrekt an die Ebene3 übertragen!
- Der ursprüngliche Sender läuft jetzt aber in den Timeout rein während das Paket gerade eintrudelt...

So, jetzt haben wir den Salat: TCP hat das Pakt schon bestätigt und ich habe es nicht empfangen!!!!

Das ist mein Problem! Hab hier ein Beispiel wo dies genau so passiert!

Jochen Kalmbach schrieb:

PS: Mir würde es ausreichen, wenn man für jede Nachricht eine neue Verbindung zwischen CLient und Server aufbaut; das ich für mich als Beispiel ok.

dann haste es doch. für sowas ist TCP ja da. sender baut verbindung auf, sendet seine nachricht, der empfänger macht als quittierung die verbindung wieder zu. sobald irgendwelche anomalien auftreten (z.b. verbindung wird durch RST statt durch FIN-FIN geschlossen) wissen beide, das etwas nicht geklappt hat. der empfänger schmeisst im fehlerfall die message weg und der sender versucht's nochmal.

Danke für den Hinweis... sowas ähnliches habe ich auch schon gedacht aber reicht mir das wirklich? Deckt das auch mein gerade geschilderten Fall ab?

pale dog schrieb:

Jochen Kalmbach schrieb:

PS: Mir würde es ausreichen, wenn man für jede Nachricht eine neue Verbindung zwischen CLient und Server aufbaut; das ich für mich als Beispiel ok.

dann haste es doch. für sowas ist TCP ja da. sender baut verbindung auf, sendet seine nachricht, der empfänger macht als quittierung die verbindung wieder zu. sobald irgendwelche anomalien auftreten (z.b. verbindung wird durch RST statt durch FIN-FIN geschlossen) wissen beide, das etwas nicht geklappt hat. der empfänger schmeisst im fehlerfall die message weg und der sender versucht's nochmal.

Danke für den Hinweis... sowas ähnliches habe ich auch schon gedacht aber reicht mir das wirklich? Deckt das auch mein gerade geschilderten Fall ab?

TCP gibt jedem Paket eine Sequenz-Nummer um das beschriebene Problem zu verhindern. Wenn ich dich richtig verstanden habe hast du den Fall beschrieben, dass die Empfangs-Bestätigung zwar losgeschickt wurde, aber zu spät beim ursprünglichen Sender eintrifft. Dann geht der Sender davon aus, dass das Paket verloren gegangen ist und schickt es nochmal los. Der Empfänger kann dann bei TCP anhand der Sequenz-Nummer feststellen, dass er dieses Paket schon einmal erhalten hat.

pale dog schrieb:

Jochen Kalmbach schrieb:

PS: Mir würde es ausreichen, wenn man für jede Nachricht eine neue Verbindung zwischen CLient und Server aufbaut; das ich für mich als Beispiel ok.

dann haste es doch. für sowas ist TCP ja da. sender baut verbindung auf, sendet seine nachricht, der empfänger macht als quittierung die verbindung wieder zu. sobald irgendwelche anomalien auftreten (z.b. verbindung wird durch RST statt durch FIN-FIN geschlossen) wissen beide, das etwas nicht geklappt hat. der empfänger schmeisst im fehlerfall die message weg und der sender versucht's nochmal.

Danke für den Hinweis... sowas ähnliches habe ich auch schon gedacht aber reicht mir das wirklich? Deckt das auch mein gerade geschilderten Fall ab?

eigentlich schon. angenommen der empfänger schliesst die verbindung nicht, weil z.b. das netzwerk so langsam ist und er noch auf die restlichen daten wartet. in dem fall (time out) schliesst der sender die verbindung (ein hartes closesockt == RST), was der empfänger seinerseits registrieren kann. passiert selbst das nicht (netzwerkausfall genau in dem augenblick) läuft der empfänger einerseits in einen timeout und verwirft alles bisher empfangenen fragmente.
also alles, was von dem vorgegebenen schema abweicht (sender: connect-send, empfänger-close -> graceful disconnect auf beiden seiten), gilt als misslungene übertragung.
beim normalen verbindungsabbau müssen beiden TCP's mitspielen. das müsste eigentlich reichen...

Windos verwaltet die Pakete in eine Art "Schieberegister".

http://de.wikipedia.org/wiki/FIFO
die anwendung schickt einzelne bytes rein (stream), der TCP stack packt selbständig pakete daraus (für darunterliegende, paketorientierte layer).

Und auf der unterste Ebene heisst das dann Frames. Hasst du vergessen....

ja, beim snooker heisst es auch frames

Was du schreibst erinnert mich daran wie ich vor dem Problem stand gewisse Daten (Events aus einem Log) zu übertragen. Dabei war wichtig dass die Daten Clientseitig erst gelöscht werden wenn sie übertragen und am Server gespeichert wurden, und dass Daten nicht 2x am Server eingetragen wurden.
Die Lösung: man verpasst jedem Datensatz Clientseitig eine unique ID (ich hab' einfach ne GUID genommen).
Dann schickt man alle Datensätze an den Server. Der Server verwirft alle Datensätze mit einer bereits bekannten GUID, alle anderen werden abgespeichert. Wenn alles abgespeichert ist schickt der Server ein ACK an den Client, woraufhin der alle übertragenen Datensätze löscht.
Wird der Vorgang unterbrochen werden einfach alle alten Datensätze bei der nächsten Übertragung nochmal mitgeschickt. Ob die dann schon eingetragen wurden oder nicht ist egal, da ja bereits eingetragene Datensätze anhand ihrere GUID erkannt und verworfen werden.

Vielleicht hilft dir das weiter.

Auf der Empfängerseite habe ich beim "recv" als Timeout auch 2 Sekunden angegeben!!!!
So was passieren kann ist folgendes:

2 Sekunden timeout erscheinen mir aber auch viel zu kurz für das beschriebene scenario. Ich würde da eher sowas wie 10 Sekunden erwarten. Der Timeout sollte ja shcon so gewählt werden das er im Normalbetrieb nicht erreicht wird. Und wie Du selber beschreibst sind 2 Skunden ja im Normalbetrieb durchaus möglich.

TCP gibt jedem Paket eine Sequenz-Nummer um das beschriebene Problem zu verhindern. Wenn ich dich richtig verstanden habe hast du den Fall beschrieben, dass die Empfangs-Bestätigung zwar losgeschickt wurde, aber zu spät beim ursprünglichen Sender eintrifft. Dann geht der Sender davon aus, dass das Paket verloren gegangen ist und schickt es nochmal los. Der Empfänger kann dann bei TCP anhand der Sequenz-Nummer feststellen, dass er dieses Paket schon einmal erhalten hat.

Das hilft mir aber nichts, da ich mich nicht auf ISO-Ebene 3 befinde, sondern auf ISO-Ebene 8!

eigentlich schon. angenommen der empfänger schliesst die verbindung nicht, weil z.b. das netzwerk so langsam ist und er noch auf die restlichen daten wartet. in dem fall (time out) schliesst der sender die verbindung (ein hartes closesockt == RST), was der empfänger seinerseits registrieren kann. passiert selbst das nicht (netzwerkausfall genau in dem augenblick) läuft der empfänger einerseits in einen timeout und verwirft alles bisher empfangenen fragmente.
also alles, was von dem vorgegebenen schema abweicht (sender: connect-send, empfänger-close -> graceful disconnect auf beiden seiten), gilt als misslungene übertragung.
beim normalen verbindungsabbau müssen beiden TCP's mitspielen. das müsste eigentlich reichen...

Und wie stelle ich jetzt fest ob die Verbindung "richtig" geschlossen wurde... ich hab doch nur ein FD_CLOSE!?

Windos verwaltet die Pakete in eine Art "Schieberegister".
Schickt diese ab und wartet auf die Quittung vom Empfäneger.
Wenn die Quittierung vollständig ist, wird das Schieberegister über seine Breite auf die nächste Pakete geschoben, sonst wird das wiederholt und nach n versuchen als failed eingestufft.

Wie gesagt, das Betrifft nur die ISO-Ebene 3!!! Die Pakete kommen da ja auch wunderbar an! und werden eben im Treiber jetzt gepuffert bis sie jemand abholt!
Ich bin aber mit meiner Anwendung auf Ebene 8 und hab jetzt das Problem dass die Daten womöglich gerade auf Ebene 3 eingetroffen sind ich auf Ebene 8 aber gleichzeitig in den Timeout reinlaufe. Somit wurden die Daten perfekt auf EBene 3 übertragen, aber ich hab sie nicht bekommen...

hustbaer schrieb:

Ok, also du hast grundsätzlich 2 Fälle: "ja" -> alles angekommen wie es sollte und "nein" -> nicht angekommen.
Mittels 2x Empfang quittieren (1x Empfang der Nachricht und 1x Empfand der Bestätigung) kannst du "sicher ja" feststellen. Wenn dabei allerdings etwas daneben geht heisst das nicht "sicher nein", sondern eben "unbekannt: ja oder nein".

Endlich einer der mich versteht!

hustbaer schrieb:

Was du schreibst erinnert mich daran wie ich vor dem Problem stand gewisse Daten (Events aus einem Log) zu übertragen. Dabei war wichtig dass die Daten Clientseitig erst gelöscht werden wenn sie übertragen und am Server gespeichert wurden, und dass Daten nicht 2x am Server eingetragen wurden.
Die Lösung: man verpasst jedem Datensatz Clientseitig eine unique ID (ich hab' einfach ne GUID genommen).
Dann schickt man alle Datensätze an den Server. Der Server verwirft alle Datensätze mit einer bereits bekannten GUID, alle anderen werden abgespeichert.

Wenn alles abgespeichert ist schickt der Server ein ACK an den Client, woraufhin der alle übertragenen Datensätze löscht.

Wird der Vorgang unterbrochen werden einfach alle alten Datensätze bei der nächsten Übertragung nochmal mitgeschickt. Ob die dann schon eingetragen wurden oder nicht ist egal, da ja bereits eingetragene Datensätze anhand ihrere GUID erkannt und verworfen werden.

Vielleicht hilft dir das weiter.

Das ist bisher auch die Lösung die ich mir vorstellen kann... leider ist das nicht so einfach mit einer eindeutigen ID... ich müsste mir ja auf der Server-Seite *alle* IDs merken und immer nachschlagen. Das ist etwas "overpowered"...

Sowas muss es doch (einfacher) geben!!! 2-Phase-Commit-Protokoll... ich hab bloß noch nichts gefunden wie man das auf TCP anwendet...

Jochen Kalmbach schrieb:

Auf der Empfängerseite habe ich beim "recv" als Timeout auch 2 Sekunden angegeben!!!!

2 Sekunden timeout erscheinen mir aber auch viel zu kurz für das beschriebene scenario. Ich würde da eher sowas wie 10 Sekunden erwarten. Der Timeout sollte ja shcon so gewählt werden das er im Normalbetrieb nicht erreicht wird. Und wie Du selber beschreibst sind 2 Skunden ja im Normalbetrieb durchaus möglich.

Die länge des Timeouts spielt bei "zuverlässig" *keine* Rolle! Entweder eine Übertragung ist zuverlässig oder nicht!
Und mir geht ja gerade *nicht* um den Normalbetrieb!

loks schrieb:

Jochen Kalmbach schrieb:

Auf der Empfängerseite habe ich beim "recv" als Timeout auch 2 Sekunden angegeben!!!!

2 Sekunden timeout erscheinen mir aber auch viel zu kurz für das beschriebene scenario. Ich würde da eher sowas wie 10 Sekunden erwarten. Der Timeout sollte ja shcon so gewählt werden das er im Normalbetrieb nicht erreicht wird. Und wie Du selber beschreibst sind 2 Skunden ja im Normalbetrieb durchaus möglich.

Die länge des Timeouts spielt bei "zuverlässig" *keine* Rolle! Entweder eine Übertragung ist zuverlässig oder nicht!
Und mir geht ja gerade *nicht* um den Normalbetrieb!

Unzuverlässig definiert sich doch darüber das Pakete verloren gehen. Ein timeout gibt dabei den Zeitpunkt an, ab dem ein Paket als verloren gilt wenn es bis dato nicht erschienen ist. Und 2 Sekunden erscheinen mir in em Zusammenhang als zu kurz, weil damit nach Deiner beschreibung ja Pakete als verloren betrachtet werden, die einfach nur "zu langsam" waren... Du sagst ja selber:

Jochen Kalmbach schrieb:

Wie gesagt, das Betrifft nur die ISO-Ebene 3!!! Die Pakete kommen da ja auch wunderbar an! und werden eben im Treiber jetzt gepuffert bis sie jemand abholt!
Ich bin aber mit meiner Anwendung auf Ebene 8 und hab jetzt das Problem dass die Daten womöglich gerade auf Ebene 3 eingetroffen sind ich auf Ebene 8 aber gleichzeitig in den Timeout reinlaufe. Somit wurden die Daten perfekt auf EBene 3 übertragen, aber ich hab sie nicht bekommen...

Demnach wird deine Übertragung unzuverlässig (Ebene 8 erkennt verlorene Pakete) obwohl diese eigentlich angekommen sein (liegen auf ebene 3). Daher meine Frage: Warum ein so kurzer timeout?

Warum ein so kurzer timeout?

Auch wenn ich mein Timeout auf 10 Sec machen hat sich das Problem nicht gelöst... wenn das Kundennetzt es erst erlaubt nach 10 sec. die Daten auf Ebene 3 korrekt zu übertragen hab ich auch nix gewonnen...

Jetzt hab ich nur noch das Problem, dass ich mehrere Clients haben kann... die wissen ja nix voneinandern, somit können diese auch keine "forlaufende" ID bilden...

der server kann ja anhand der 'sockaddr_in' (portnummer und ip adresse die der client benutzt) die clients unterscheiden. wenn z.b. auf einer client-maschine zwei instanzen der client-software eine verbindung zum server haben, kann dieser anhand der portnummern die clients unterscheiden, obwohl die ip-adressen gleich sind.

Hallo hustbaer!

hustbaer schrieb:

Ok, also du hast grundsätzlich 2 Fälle: "ja" -> alles angekommen wie es sollte und "nein" -> nicht angekommen.
Mittels 2x Empfang quittieren (1x Empfang der Nachricht und 1x Empfand der Bestätigung) kannst du "sicher ja" feststellen. Wenn dabei allerdings etwas daneben geht heisst das nicht "sicher nein", sondern eben "unbekannt: ja oder nein".

Endlich einer der mich versteht!

Hehe, ja, weil ich eben genau so ein Problem schon hatte

hustbaer schrieb:

Was du schreibst erinnert mich daran wie ich vor dem Problem stand gewisse Daten (Events aus einem Log) zu übertragen. Dabei war wichtig dass die Daten Clientseitig erst gelöscht werden wenn sie übertragen und am Server gespeichert wurden, und dass Daten nicht 2x am Server eingetragen wurden.
Die Lösung: man verpasst jedem Datensatz Clientseitig eine unique ID (ich hab' einfach ne GUID genommen).
Dann schickt man alle Datensätze an den Server. Der Server verwirft alle Datensätze mit einer bereits bekannten GUID, alle anderen werden abgespeichert.

Wenn alles abgespeichert ist schickt der Server ein ACK an den Client, woraufhin der alle übertragenen Datensätze löscht.

Wird der Vorgang unterbrochen werden einfach alle alten Datensätze bei der nächsten Übertragung nochmal mitgeschickt. Ob die dann schon eingetragen wurden oder nicht ist egal, da ja bereits eingetragene Datensätze anhand ihrere GUID erkannt und verworfen werden.

Vielleicht hilft dir das weiter.

Das ist bisher auch die Lösung die ich mir vorstellen kann... leider ist das nicht so einfach mit einer eindeutigen ID... ich müsste mir ja auf der Server-Seite *alle* IDs merken und immer nachschlagen. Das ist etwas "overpowered"...

Sowas muss es doch (einfacher) geben!!! 2-Phase-Commit-Protokoll... ich hab bloß noch nichts gefunden wie man das auf TCP anwendet...

Naja, du musst dir auf der Server Seite nur die IDs merken von Transaktionen von denen der Server nicht sicher sein kann dass der Client bereits weiss dass sie auch committed wurden, und dass der Client sie seinerseits als "fertig" markiert hat (bzw. einfach gelöscht hat).

Nachdem der Server eine Transaktion "committed" hat schickt er einfach zum Client "Transaktion #1234 ist committed". Der Client kann nun seinerseits diese Transaktion löschen bzw. als "fertig" markieren, und _danach_ schickt er an den Server "OK, habe Transaktion #1234 als fertig markiert". Sobald der Server das empfangen hat kann er die Daten über Transaktion #1234 löschen, da er sicher sein kann diese vom Client nicht nochmals geschickt zu bekommen.

Das einzige was hier nun passieren kann ist dass der Server eine Transaktion (die bereits committed ist) für einen Client noch gespeichert hat, der Client diese aber schon gelöscht hat (da die Verbindung unterbrochen wurde bevor der Client das "OK, habe Transaktion #1234 als fertig markiert" an den Server schicken konnte).
Der Fall ist aber nicht weiter tragisch, das lässt sich einfach damit regeln dass bei jedem Verbindungsaufbau der Server die IDs der Transaktionen die bereits committed wurden an den Client schickt, und der Client diese dann auf seiner Seite löscht. Hat er sie schon gelöscht findet er sie nicht und ignoriert sie einfach, in dem Fall schickt er dann ein "OK, habe Transaktion #1234 nicht gefunden, muss ich damals schon gelöscht haben" an den Server, und dieser kann die Daten wiederum löschen.

Soetwas würde ich allerdings nur implementieren wenn das System nicht sowieso Daten über sämtliche Transaktionen irgendwo aufheben muss. Das Nachschlagen der IDs sehe ich nicht als Problem ansich, höchstens eben den Speicherplatz der dafür draufgeht, was aber eben nur ein Problem ist wenn nicht sowieso alles aufgehoben werden muss.
Das Nachschlagen in einer kleinen Detailtabelle (bzw. einem "Covering Index") mit nur Transaktions ID + Zustand sollte auf jeden Fall sehr schnell gehen - so eine GUID ist gerademal 16 Byte lang, mit Zustand und Overhead kommt das auf sagen wir mal 17-20 Byte pro Zeile - regt mich ehrlich gesagt nicht sonderlich auf. So viele Zeilen können das garnicht sein dass ein B-Baum da besonders tief werden könnte.
Und wenn man statt GUIDs noch fortlaufende Nummern vergibt muss auch nur ein ganz kleiner Teil dieser Tabelle im Speicher gehalten werden, nämlich die IDs der letzten paar Tage.
(Und wenn man die IDs Serverseitig vergibt sollte man auch mit 8 oder 10 Byte auskommen, was die Tabelle nochmal schmäler macht)

p.S.: über Timeouts oder die Details von TCP/IP muss (bzw. sollte oder noch besser: darf) man sich bei sowas überhaupt keine Gedanken machen. Man behandelt die TCP/IP Verbindung einfach als Verbindung die jederzeit abreissen kann, und wenn sie abreisst muss man davon ausgehen dass minimal garnix bis maximal alles was seit der letzten Bestätigung zur Gegenstelle geschickt wurde nicht angenommen ist. Dadurch erübrigt es sich auch darüber nachzudenken ob die Gegenstelle vielleicht abstürzen könnte oder den Strom verliert oder sonstwas -- wenn das Protokoll mit "Verbindung kann jederzeit abreissen" klarkommt sind diese Fälle alle automatisch mit abgedeckt.