UDP-Buffer // Pakete empfangen
-
Hallo zusammen.
Hab mal eine allgemeine Frage zur Funktion des UDP-Buffers.
Mit setsockopt() kann ich ja die Buffergröße einstellen.
Angenommen es liegen 50 Pakete im Buffer, jedes 100 Byte groß und ich hole diese mit recv() ab, dann wird bei mir immer ein Paket abgeholt. Ich muss diese also in einer Schleife abholen. Gibt es auch eine Möglichkeit alle 50 gleichzeitig, mit einem recv() Aufruf abzuholen oder wird standardmäßig immer nur ein Paket abgeholt?
-
nimm NTP. da kommen die pakete ohne zeitverlust in 0ms an.
-
NTP baut doch aber auf UDP auf. Versteh ich jetzt nicht ganz.
Die Sache ist auch das das Gerät von dem ich die Daten bekomme mir diese über UDP schickt. Da kann ich nichts mit NTP anfangen.
-
rüdiger_at_home schrieb:
nimm NTP. da kommen die pakete ohne zeitverlust in 0ms an.
Ist klar das du diese Aussage nicht verstehst, weil dich hier einer versucht hat zu verarschen.
-
nimm WSARecv(From)
-
ntp-freak schrieb:
nimm WSARecv(From)
ntp-freak???
Sorry ich glaub jetzt hier erstmal garnix bis nich ein registriertes Mitglied geantwortet hat.
-
Ich glaube, sobald die Pakete im Buffer liegen, sind es eben keine "Pakete" mehr, sondern nur noch hintereinanderliegende Bytes. Und klar kannst du mit recv auch mehr Daten abholen. Also einfach einen Buffer mit 10 KB anlegen, recv mit 10.000 als Parameter "len" aufrufen und die Daten in den Buffer schreiben lassen. Mit dem Rückgabewert kriegst du ja raus, wieviele Bytes dann wirklich im Buffer lagen.
Wie kommst du eigentlich drauf, dass man immer nur "1 Paket" abholen kann?Kleiner Zusatz: Ich kann nur von TCP sprechen, UDP funktioniert in dieser Hinsicht afaik aber ziemlich ähnlich.
edit: Ist anscheinend Schwachsinn für UDP.
-
Hallo,
Badestrand schrieb:
Ich glaube, sobald die Pakete im Buffer liegen, sind es eben keine "Pakete" mehr, sondern nur noch hintereinanderliegende Bytes. Und klar kannst du mit recv auch mehr Daten abholen. Also einfach einen Buffer mit 10 KB anlegen, recv mit 10.000 als Parameter "len" aufrufen und die Daten in den Buffer schreiben lassen. Mit dem Rückgabewert kriegst du ja raus, wieviele Bytes dann wirklich im Buffer lagen.
Wie kommst du eigentlich drauf, dass man immer nur "1 Paket" abholen kann?Kleiner Zusatz: Ich kann nur von TCP sprechen, UDP funktioniert in dieser Hinsicht afaik aber ziemlich ähnlich.
oh Mann, oh Mann.
An den TE: Ruf recv() in einer Schleife auf und hänge die Pakete hintereinander. Das ist der einfachste (und wahrscheinlich der einzige) Weg. Das OS speichert die Pakete nämlich nicht als "hintereinanderliegende Bytes", sondern als Pakete mit Zusatzdaten wie Absender-Struktur.
Chris
-
Hallo.
Badestrand schrieb:
Wie kommst du eigentlich drauf, dass man immer nur "1 Paket" abholen kann?
Weil ich den UDP-Buffer >60000 Byte gemacht habe. Der recv() Funktion einen Speicher von 1000Byte übergebe in den die Daten geschrieben werden sollen und ich trotzdem immer nur ein 100 Byte Paket empfange, obwohl der Puffer voll ist.
Wie du richtig sagst erhält man mit dem Rückgabewert wieviele Packete Bytes man empfangen hat und das sind jedesmal 100 Byte.
Vielleicht gibt es ja irgend einen Parameter den ich evtl mit ner ander Funktion erst setzen muss damit ich mehrere Pakete gleichzeitig abholen kann.
-
ChrisM schrieb:
An den TE: Ruf recv() in einer Schleife auf und hänge die Pakete hintereinander.
Genau das tu ich im Moment. Aber wie gesagt man erhält ja immer nur ein Paket.
-
Welle101 schrieb:
ntp-freak schrieb:
nimm WSARecv(From)
ntp-freak???
Sorry ich glaub jetzt hier erstmal garnix bis nich ein registriertes Mitglied geantwortet hat.sehr dumme einstellung, ich habe dir nämlich die lösung genannt, im gegensatz zu den registrierten usern
-
Dann wird das sicher auch nen Registrierter bestätigen können.
-
Hallo,
Welle101 schrieb:
ChrisM schrieb:
An den TE: Ruf recv() in einer Schleife auf und hänge die Pakete hintereinander.
Genau das tu ich im Moment. Aber wie gesagt man erhält ja immer nur ein Paket.
ja, klar, das stimmt. Aber du kannst es dir ja dann mit memcpy() zusammenbauen.
Ich glaube nicht, dass es unter irgendeinem OS möglich ist, Zugriff auf eine Art Paketpuffer, in dem alle Pakete am Stück drinstehen, zugriffen. Standardkonform gehts auf keinen Fall. Ganz einfach, weil es diesen Puffer nirgends gibt (ich vermute, intern werden die angekommenen Pakete in einer Linked List oder so verwaltet).
Chris
-
Sicher das nicht einfach der Sender zu lahm ist, jeweils nur 100 Bytes rauskloppt und dann nen paar ms woanders mit beschäftigt ist?
-
Ganz egal wie die Pakete intern verwaltet werden, man muss sich diese immer selbst zusammenbauen (EDIT: EIN Paket bekommt man natürlich immer als ganzes, "zusammenbauen" meine ich hier natürlich im Sinn mehrere Pakete zu etwas grösserem zusammenbauen /EDIT), da die Reihenfolge nicht garantiert ist.
Wenn man 3 Pakete A, B, C wegschickt kann es sein dass A, B, C ankommt, kann aber genausogut sein dass A, C oder C, A, B oder nur B oder sonstwas ankommt.
Was soll das dann bringen wenn man die Pakete in der Reihenfolge wie sie angekommen sind hintereinanderhängt?Lösung: man muss mit jedem Paket genug Informationen mitschicken damit der Empfänger weiss wie er die Daten in dem Paket zu verstehen hat, und sich die Pakete auf der Empfangsseite dann selbst sortieren/zusammenhängen/... wie man es braucht. Dieser Prozess muss natürlich auch mit verlorengegangenen Paketen klarkommen.
-
Badestrand schrieb:
Ich glaube, sobald die Pakete im Buffer liegen, sind es eben keine "Pakete" mehr, sondern nur noch hintereinanderliegende Bytes. Und klar kannst du mit recv auch mehr Daten abholen. Also einfach einen Buffer mit 10 KB anlegen, recv mit 10.000 als Parameter "len" aufrufen und die Daten in den Buffer schreiben lassen. Mit dem Rückgabewert kriegst du ja raus, wieviele Bytes dann wirklich im Buffer lagen.
Wie kommst du eigentlich drauf, dass man immer nur "1 Paket" abholen kann?Kleiner Zusatz: Ich kann nur von TCP sprechen, UDP funktioniert in dieser Hinsicht afaik aber ziemlich ähnlich.
Für TCP hast du auch recht, aber das garantiert dir ja die Anordnung der Daten in der logischen Reihenfolge und nicht in der Reihenfolge wie sie ankommen beim Empfänger.
-
Nimm Linux.
