Wechsel von UDP zu TCP
-
Streng genommen benutze ich gar nichts, da es nicht mein Code ist
Das Betriebssystem heißt RTOS-UH, ich weiß nicht inwiefern das außerhalb der Uni bekannt ist. Was ist mit TCP-Stack gemeint? Sorry, bin wie gesagt neu in dem Bereich.
-
Kommt drauf an was hin und hergeschickt wird.
Um es mal kurz und knapp zu sagen:
UDP ist ungesichert, TCP ist gesichert, dafür aber auch langsamer, weil es halt die Kommunikation überwacht.
-
Das ist mir klar, es geht im wesentlichen um ein paar integer variablen, welche sensordaten von Gelenken eines Roboters sind. Da diese Daten graphisch verarbeitet werden, aber durch die UDP-Verwendung Pakete verloren gehen, möchten die hier von mir, dass ich das System auf TCP umstelle.
-
Da werden wohl hohe Durchsatzraten benötigt.
Ich würd da lieber ein Protokoll drüber setzen, dein Programm versendet die Daten als UDP Paket, dem z.B. eine MsgNr vorangestellt wird. Der Empfänger quittiert dies, indem er diese MsgNr zurückschickt.
Kommt nach n (milli)sekunden keine Bestätigung, wiederholt der Sender einfach das letzte Paket. Der Empfanger sollte natürlich doppelte Pakete verwerfen, d.h. kommt die letzte empfangene MsgNr nochmal an, so sendet der Empfänger zwar die Quittierung, verarbeitet die Daten aber nicht weiter, die hatte er ja schon beim letzten Mal empfangen.
-
Burkhi schrieb:
Da werden wohl hohe Durchsatzraten benötigt.
Ich würd da lieber ein Protokoll drüber setzen, dein Programm versendet die Daten als UDP Paket, dem z.B. eine MsgNr vorangestellt wird. Der Empfänger quittiert dies, indem er diese MsgNr zurückschickt.
Kommt nach n (milli)sekunden keine Bestätigung, wiederholt der Sender einfach das letzte Paket. Der Empfanger sollte natürlich doppelte Pakete verwerfen, d.h. kommt die letzte empfangene MsgNr nochmal an, so sendet der Empfänger zwar die Quittierung, verarbeitet die Daten aber nicht weiter, die hatte er ja schon beim letzten Mal empfangen.Das war meine erste Idee, aber die Leute hier meinten ich solle das wirklich auf TCP umstellen.
-
Warum sollte dadurch der Code unbrauchbar werden?
Wenn schon dann eher das Programm ansich, wenn auf "Realzeit" Wert gelegt wird.
Aber egal, am Code ändert sich eigentlich gar nichts.
Ich nehm mal an das OS nutzt auch die BSD Sachen. Oder wurde da alles neu entwickelt?
Wenn BSD Socket, dann geht es ja eigentlich nur um diese Zeile:
int sd; sd = socket(AF_INET, SOCK_STREAM, 0);Der letzte Parameter legt fest ob TCP, UDP oder automatisch gewählt wird (0 = auto.)
Ansonsten ändert sich da gar nix.
-
Namenloser324 schrieb:
Das war meine erste Idee, aber die Leute hier meinten ich solle das wirklich auf TCP umstellen.
Ja, da übliche "blabla", die haben mal davon gehört, das TCP die Kommunikation überwacht, deshalb ist es besser. Kenne ich auch.
Du selbst hast aber keine Kontrolle darüber, ob deine Daten wirklich angekommen sind. Bis TCP einen Verbindungsabbruch meldet, kann es schon mal 1/2h dauern, dann sind die Daten von 1/2h weg.
Also wenn TCP unbedingt sein soll:
Du musst zuerst festlegen, wer Server und wer Client ist, vermutlich wird die "Gelenke" App Client spielen und die App, die die Daten entgegenimmt, Server. Dann musst du erstmal den Server auf "Listen" stellen. Der Client muss eine Verbindung zum Server aufbauen, die der Server dann akzeptieren muss.Hier ein Beispiel:
-
Namenloser324 schrieb:
Was ist mit TCP-Stack gemeint?
Die API von deinem Netzwerk-Protokol.
BSD-Socket ist einer.
Es gibt aber auch andere, z.B für Microcontroller.
-
RTOS-UH hält sich nicht an POSIX, sondern hat eine eigene Netzwerkschnittstelle.
Ich überblicke nicht im Detail, wie viel Schnittstellenzeugs bei der Umstellung von udp nach tcp umgestellt werden muss; wenn ich das richtig im Kopf habe, gibt es da protokollweise verschiedene Funktionsfamilien, also könnte es eine ganze Menge sein. Grundsätzlich ist aber, sobald du einmal den Datenverkehr geregelt hast und die Paketinhalte verarbeitest, nicht zu erwarten, dass du irgendetwas ganz anders machen musst (sofern du dich nicht am oberen Ende der MTU bewegst), denn die TCP-Pakete kommen in einer Reihenfolge an, die bei UDP-Übetragung auch möglich wäre. Wahrscheinlich ist allerdings, dass eine Menge Verwaltungscode überflüssig wird, weil der TCP-Stack seine Arbeit übernimmt.
Ansonsten solltest du darauf achten, dass du TCP_active_open respektive TCP_passive_open ein struct tcp_socket mitgibst, in dem time_out nicht zu hoch gesetzt ist. Es ist nicht damit zu rechnen, dass die Verbindung andauernd abreißt, aber wenn sie es mal tut, sollte der Roboter vermutlich nicht ewig stillstehen. Wie viel Pause im Fehlerfall akzeptabel ist, musst du allerdings selbst wissen.
-
Burkhi schrieb:
Namenloser324 schrieb:
Das war meine erste Idee, aber die Leute hier meinten ich solle das wirklich auf TCP umstellen.
Ja, da übliche "blabla", die haben mal davon gehört, das TCP die Kommunikation überwacht, deshalb ist es besser. Kenne ich auch.
Du selbst hast aber keine Kontrolle darüber, ob deine Daten wirklich angekommen sind. Bis TCP einen Verbindungsabbruch meldet, kann es schon mal 1/2h dauern, dann sind die Daten von 1/2h weg.
Also wenn TCP unbedingt sein soll:
Du musst zuerst festlegen, wer Server und wer Client ist, vermutlich wird die "Gelenke" App Client spielen und die App, die die Daten entgegenimmt, Server. Dann musst du erstmal den Server auf "Listen" stellen. Der Client muss eine Verbindung zum Server aufbauen, die der Server dann akzeptieren muss.Hier ein Beispiel:
Danke für deine Antwort.
Die Daten solten nicht verloren gehen, da sie ja zunächst zwischengespeichert werden würden(kommt noch). Dann würde ich sie erst löschen, wenn mir das TCP-Protokoll zurückgibt, dass die Daten versendet worden sind.Danke für deine Hinweise, soweit ich das bisher gelesen habe ist ja der "Listen"-Krams bei TCP kaum anders als bei UDP, eigentlich ändert sich doch nur der Send- bzw. Receiveteil, oder? Ich meine man müsste dann doch sendto und receivefrom benutzen anstelle von send und receive.
