Wie groß sollte mein Recv-Puffer sein, wenn ich recv in der Socket-Bibliothek aufrufe?

Ich habe ein paar Fragen zur Socket-Bibliothek in C. Hier ist ein Codeausschnitt, auf den ich mich in meinen Fragen beziehen werde.

char recv_buffer[3000];
recv(socket, recv_buffer, 3000, 0);

1. Wie entscheide ich, wie groß recv_buffer werden soll? Ich verwende 3000, aber es ist willkürlich.
2. was passiert wenn recv() erhält ein Paket, das größer als mein Puffer ist?
3. Wie kann ich wissen, ob ich die gesamte Nachricht erhalten habe, ohne recv erneut aufzurufen, und sie ewig warten lassen, wenn nichts zu empfangen ist?
4. Gibt es eine Möglichkeit, einen Puffer ohne festen Speicherplatz einzurichten, sodass ich ihn weiter erweitern kann, ohne befürchten zu müssen, dass der Speicherplatz knapp wird? vielleicht mit strcat um die neuesten zu verketten recv() Antwort auf den Puffer?

Ich weiß, es sind viele Fragen in einer, aber ich würde mich sehr über Antworten freuen.

Die Antworten auf diese Fragen variieren je nachdem, ob Sie einen Stream-Socket verwenden (SOCK_STREAM) oder ein Datagramm-Socket (SOCK_DGRAM) – Innerhalb von TCP/IP entspricht ersteres TCP und letzteres UDP.

Woher wissen Sie, wie groß der übergebene Puffer sein soll? recv()?

• SOCK_STREAM: Es spielt nicht wirklich eine Rolle. Wenn es sich bei Ihrem Protokoll um ein transaktionales / interaktives Protokoll handelt, wählen Sie einfach eine Größe aus, die die größte einzelne Nachricht / den größten einzelnen Befehl enthalten kann, den Sie vernünftigerweise erwarten würden (3000 ist wahrscheinlich in Ordnung). Wenn Ihr Protokoll Massendaten überträgt, können größere Puffer effizienter sein – eine gute Faustregel ist ungefähr die gleiche wie die Kernel-Empfangspuffergröße des Sockets (häufig etwa 256 KB).

• SOCK_DGRAM: Verwenden Sie einen Puffer, der groß genug ist, um das größte Paket aufzunehmen, das Ihr Protokoll auf Anwendungsebene jemals sendet. Wenn Sie UDP verwenden, sollte Ihr Protokoll auf Anwendungsebene im Allgemeinen keine Pakete senden, die größer als etwa 1400 Bytes sind, da sie sicherlich fragmentiert und neu zusammengesetzt werden müssen.

Was passiert wenn recv bekommt ein Paket größer als der Puffer?

• SOCK_STREAM: Die Frage ist nicht wirklich sinnvoll, da Stream-Sockets kein Konzept von Paketen haben – sie sind nur ein kontinuierlicher Strom von Bytes. Wenn mehr Bytes zum Lesen verfügbar sind, als Ihr Puffer Platz bietet, werden sie vom Betriebssystem in die Warteschlange gestellt und stehen für Ihren nächsten Aufruf zur Verfügung recv.

• SOCK_DGRAM: Die überzähligen Bytes werden verworfen.

Woher weiß ich, ob ich die gesamte Nachricht erhalten habe?

• SOCK_STREAM: Sie müssen eine Möglichkeit zur Bestimmung des Nachrichtenendes in Ihr Protokoll auf Anwendungsebene einbauen. Üblicherweise ist dies entweder ein Längenpräfix (das jede Nachricht mit der Länge der Nachricht beginnt) oder ein Nachrichtenende-Trennzeichen (das beispielsweise nur ein Zeilenumbruch in einem textbasierten Protokoll sein kann). Eine dritte, weniger genutzte Option besteht darin, für jede Nachricht eine feste Größe vorzuschreiben. Kombinationen dieser Optionen sind ebenfalls möglich – beispielsweise ein Header mit fester Größe, der einen Längenwert enthält.

• SOCK_DGRAM: Eine Single recv call gibt immer ein einzelnes Datagramm zurück.

Gibt es eine Möglichkeit, einen Puffer ohne festen Speicherplatz einzurichten, sodass ich ihn weiter erweitern kann, ohne befürchten zu müssen, dass der Speicherplatz knapp wird?

Nein. Sie können jedoch versuchen, die Größe des Puffers mit zu ändern realloc() (wenn es ursprünglich mit zugewiesen wurde malloc() oder calloc()das ist).

Für Streaming-Protokolle wie TCP können Sie Ihren Puffer auf jede beliebige Größe einstellen. Es werden jedoch gängige Werte empfohlen, die Potenzen von 2 sind, z. B. 4096 oder 8192.

Wenn mehr Daten vorhanden sind als Ihr Puffer, werden sie einfach im Kernel für Ihren nächsten Aufruf gespeichert recv.

Ja, Sie können Ihren Puffer weiter vergrößern. Sie können einen Recv in die Mitte des Puffers beginnend bei offset durchführen idxDu würdest:

recv(socket, recv_buffer + idx, recv_buffer_size - idx, 0);

Wenn Sie eine haben SOCK_STREAM Steckdose, recv bekommt nur “bis zu den ersten 3000 Bytes” aus dem Stream. Es gibt keine klare Anleitung, wie groß der Puffer sein soll: Wie groß ein Stream ist, weiß man erst, wenn alles fertig ist ;-).

Wenn Sie eine haben SOCK_DGRAM Socket, und das Datagramm ist größer als der Puffer, recv füllt den Puffer mit dem ersten Teil des Datagramms, gibt -1 zurück und setzt errno auf EMSGSIZE. Wenn das Protokoll UDP ist, bedeutet dies leider, dass der Rest des Datagramms verloren geht – ein Teil dessen, warum UDP als ein bezeichnet wird unzuverlässig Protokoll (Ich weiß, dass es zuverlässige Datagramm-Protokolle gibt, aber sie sind nicht sehr beliebt — ich könnte keins aus der TCP/IP-Familie nennen, obwohl ich letzteres ziemlich gut kenne;-).

Um einen Puffer dynamisch zu vergrößern, ordnen Sie ihn zunächst mit zu malloc und verwenden realloc wie benötigt. Aber das wird dir nicht weiterhelfen recv aus einer UDP-Quelle, leider.

Zum SOCK_STREAM Socket spielt die Puffergröße keine Rolle, da Sie nur einige der wartenden Bytes abrufen und bei einem nächsten Aufruf mehr abrufen können. Wählen Sie einfach die Puffergröße, die Sie sich leisten können.

Zum SOCK_DGRAM Socket erhalten Sie den passenden Teil der wartenden Nachricht und der Rest wird verworfen. Sie können die Größe des wartenden Datagramms mit dem folgenden ioctl abrufen:

#include <sys/ioctl.h>
int size;
ioctl(sockfd, FIONREAD, &size);

Alternativ können Sie verwenden MSG_PEEK und MSG_TRUNC Flaggen der recv() aufrufen, um die wartende Datagrammgröße zu erhalten.

ssize_t size = recv(sockfd, buf, len, MSG_PEEK | MSG_TRUNC);

Du brauchst MSG_PEEK um die wartende Nachricht zu spähen (nicht zu empfangen) – recv gibt die tatsächliche, nicht abgeschnittene Größe zurück; und du brauchst MSG_TRUNC damit Ihr aktueller Puffer nicht überläuft.

Dann kannst du einfach malloc(size) der echte Puffer und recv() Datagramm.

Ihre Frage lässt sich nicht pauschal beantworten, da Technik immer implementierungsspezifisch sein muss. Ich gehe davon aus, dass Sie in UDP kommunizieren, da die Größe des eingehenden Puffers kein Problem für die TCP-Kommunikation darstellt.

Entsprechend RFC-768, kann die Paketgröße (einschließlich Header) für UDP zwischen 8 und 65.515 Byte liegen. Die ausfallsichere Größe für den eingehenden Puffer beträgt also 65.507 Bytes (~64 KB).

Allerdings können nicht alle großen Pakete von Netzwerkgeräten richtig geroutet werden. Weitere Informationen finden Sie in der bestehenden Diskussion:

Was ist die optimale Größe eines UDP-Pakets für maximalen Durchsatz?
Was ist die größte sichere UDP-Paketgröße im Internet?

16kb ist ungefähr richtig; Wenn Sie Gigabit-Ethernet verwenden, kann jedes Paket 9 KB groß sein.