- Sliding-Window-Algorithmus von TCP nachprogrammieren? Aufwand?
- Time-Out so setzen, dass, wenn ein Packet nicht ankommt, sofort ein Reconnect durchgeführt wird und die Daten wieder neu synchronisiert werden.
- Accepts schicken - Netzwerkauslastung? Aufwand?
- ...
Samstag, 3. Januar 2009
send - Zuverlässige Übertragung?
Important TODO: Sicherstellen, dass Daten an der Gegenstelle ankommen. Die send-Funktion tut dies anscheinend laut der MSDN-Dokumentation NICHT! Mögliche Lösungen:
Abonnieren
Kommentare zum Post (Atom)
M.E. ist die Übertragung per TCP/IP (socket) schon sicher, natürlich nur in gewissem Rahmen. IP (wird von TCP/IP verwendet) ist hingegen nicht sicher, es ist nicht einmal die Reihenfolge der Pakete gesichert. Die Frage ist, welche Verbindung verwenden Sie?
AntwortenLöschenHier ein Zitat aus der Wikipedia:
Im Gegensatz zum verbindungslosen UDP implementiert TCP einen bidirektionalen, byte-orientierten, zuverlässigen Datenstrom zwischen zwei Endpunkten. Das darunterliegende Protokoll (IP) ist paketorientiert, wobei Datenpakete verlorengehen können, in verkehrter Reihenfolge ankommen dürfen und sogar doppelt empfangen werden können. TCP wurde entwickelt, um mit der Unsicherheit der darunterliegenden Schichten umzugehen. Es prüft daher die Integrität der Daten mittels der Prüfsumme im Paketkopf und stellt die Reihenfolge durch Sequenznummern sicher. Der Sender wiederholt das Senden von Paketen, falls keine Bestätigung innerhalb einer bestimmten Zeitspanne (Timeout) eintrifft. Die Daten der Pakete werden beim Empfänger in einem Puffer in der richtigen Reihenfolge zu einem Datenstrom zusammengefügt und doppelte Pakete verworfen.
Der Datentransfer kann selbstverständlich jederzeit nach dem „Aufbau einer Verbindung“ gestört, verzögert oder ganz unterbrochen werden. Das Übertragungssystem läuft dann in einen Timeout. Der vorab getätigte „Verbindungsaufbau“ stellt also keinerlei Gewähr für eine nachfolgende, dauerhaft gesicherte Übertragung dar.
--- Zitat Ende ---
Sie müssen m.E. nur erkennen, ob die Verbindung überhaupt funktioniert. Das geht einerseits über die Timeouts (select) und andererseits über ein geeignetes Applikationsprotokoll, in das ein Watchdog eingebaut ist.
Jeder Teilnehmer sendet pro Zeitfenster immer Daten, entweder fallen sowiso Daten an oder es wird ein Alive-Paket gesendet. Jeder Empfänger prüft, ob Daten innerhalb des Zeitfensters kommen. Kommen zu lange keine Daten (Verbindung unterbrochen, gestört o.ä.), so muss die Applikation etwas unternehmen, z.B. Verbindung beenden (das sollte auch der Sender beim nächsten send mitkriegen) und wieder neu aufbauen.
Sollten Sie IP verwenden, dann steigen Sie auf TCP/IP um (oder programmieren das Protokoll nach, was keinen Sinn macht).
Im Prinzip wird eh TCP verwendet, laut der Microsoft-Spezifikation heißt es komischerweise:
AntwortenLöschen" ... If no error occurs, send returns the total number of bytes sent, which can be less than the number requested to be sent in the len parameter. ... The successful completion of a send function does not indicate that the data was successfully delivered and received to the recipient. This function only indicates the data was successfully sent." Ich glaube, dass dies aber nur deswegen in der Dokumentation steht, weil WinSock prinzipiell für TCP, UDP konzipiert ist. Es sind in der Vergangenheit komischerweise manchesmal "Geisterpakete" mit falschen bzw. seltsamen Längen (-43 zum Beispiel) angekommen, was irgendwie auf ein Teilpaket hinweist. Im Prinzip sollte das Problem behoben sein, weil ab jetzt, wenn ein Client oder auch ein Server innerhalb einer bestimmten Zeitspanne keinen Ping mehr vom Server erhält, automatische ein Reconnect [mit ping vor connect] durchgeführt wird. Nach dem erneuten erfolgreichen Verbinden wird automatisch der aktuelle Level, die Files und die aktuellen Zustände (wo befinden sich die Flugzeuge, Bälle, Farbpatronen, Bauobjekte? in welchem Zustand sind die Bauobjekte, Upgrades, ...) übertragen.
Jetzt ist mir wieder ein anderes Problem eingefallen: Es könnte sein, dass gerade in dem Zeitpunkt, als man einen Ball in den Turm fallen lässt, die Netzwerkverbindung abbricht. Jetzt geht eigentlich dieses Paket, das bereichten soll, dass ein Energieball in den Energieturm geworfen wurde, verloren. Alternativ dazu könnte der Spieler an Ort und Stelle "stecken" und somit beim nächsten Reconnect wieder dort weiterfliegen. Was passiert aber, wenn in Zwischenzeit schon jemand diesen Spieler mit einem Farbtupfer markiert hat? Momentan wird ein Spieler, der getrennt wird, automatisch wieder "Zuschauer", doch auch dieses Verhalten kann jemanden vlt. als "unfair" erscheinen oder nicht?
AntwortenLöschen