Wie groß sollte mein RecV-Puffer sein, wenn Recv in der Socket-Bibliothek aufgerufen wird?

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

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

1. Wie entscheide ich, wie groß recv_buffer sein soll? Ich benutze 3000, aber es ist willkürlich.
2. Was passiert, wenn recv()ein Paket empfangen wird, das größer als mein Puffer ist?
3. Wie kann ich feststellen, ob ich die gesamte Nachricht erhalten habe, ohne erneut recv aufzurufen, und sie für immer warten lassen, wenn nichts zu empfangen ist?
4. Gibt es eine Möglichkeit, einen Puffer ohne festen Speicherplatz zu erstellen, damit ich ihn weiter erweitern kann, ohne befürchten zu müssen, dass ihm der Speicherplatz ausgeht? Vielleicht verwenden, strcatum die letzte recv()Antwort auf den Puffer zu verketten ?

Ich weiß, dass es viele Fragen in einer gibt, aber ich würde mich über jede Antwort sehr freuen.

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

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

• SOCK_STREAM: Es ist nicht wirklich wichtig. 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 Befehl enthalten kann, die 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 entspricht in etwa der Größe des Kernel-Empfangspuffers 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 gesendet hat. Wenn Sie UDP verwenden, sollte Ihr Protokoll auf Anwendungsebene im Allgemeinen keine Pakete senden, die größer als etwa 1400 Byte sind, da diese sicherlich fragmentiert und neu zusammengesetzt werden müssen.

Was passiert, wenn recvein Paket größer als der Puffer wird?

• SOCK_STREAM: Die Frage ist nicht wirklich sinnvoll, da Stream-Sockets kein Paketkonzept haben - sie sind nur ein kontinuierlicher Stream 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 an zur Verfügung recv.

• SOCK_DGRAM: Die überschüssigen Bytes werden verworfen.

Wie kann ich feststellen, ob ich die gesamte Nachricht erhalten habe?

• SOCK_STREAM: Sie müssen eine Möglichkeit zum Bestimmen des Nachrichtenende in Ihr Protokoll auf Anwendungsebene integrieren. Im Allgemeinen ist dies entweder ein Längenpräfix (wobei jede Nachricht mit der Länge der Nachricht beginnt) oder ein Trennzeichen für das Ende der Nachricht (das beispielsweise nur eine neue Zeile in einem textbasierten Protokoll sein kann). Eine dritte, weniger genutzte Option besteht darin, für jede Nachricht eine feste Größe festzulegen. Kombinationen dieser Optionen sind ebenfalls möglich - beispielsweise ein Header mit fester Größe, der einen Längenwert enthält.

• SOCK_DGRAM: Ein einzelner recvAufruf gibt immer ein einzelnes Datagramm zurück.

Gibt es eine Möglichkeit, einen Puffer ohne festen Speicherplatz zu erstellen, damit ich ihn weiter erweitern kann, ohne befürchten zu müssen, dass ihm der Speicherplatz ausgeht?

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

Bei Streaming-Protokollen wie TCP können Sie Ihren Puffer auf eine beliebige Größe einstellen. Es werden jedoch gemeinsame Werte mit Potenzen von 2 wie 4096 oder 8192 empfohlen.

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

Ja, Sie können Ihren Puffer weiter vergrößern. Sie können eine Aufnahme in die Mitte des Puffers machen, beginnend mit dem Versatz idx. Sie würden Folgendes tun:

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

Wenn Sie einen SOCK_STREAMSocket haben, werden recvnur "bis zu den ersten 3000 Bytes" vom Stream abgerufen. Es gibt keine klare Anleitung, wie groß der Puffer sein soll: Das einzige Mal, wenn Sie wissen, wie groß ein Stream ist, ist, wenn alles erledigt ist ;-).

Wenn Sie einen SOCK_DGRAMSocket haben und das Datagramm größer als der Puffer ist, recvfüllt es 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 unzuverlässiges Protokoll bezeichnet wird (ich weiß, dass es zuverlässige Datagrammprotokolle gibt, aber sie sind nicht sehr beliebt - ich konnte nicht Nennen Sie einen in der TCP / IP-Familie, obwohl Sie letzteres ziemlich gut kennen ;-).

Um einen Puffer dynamisch zu vergrößern, weisen Sie ihn zunächst zu mallocund verwenden Sie ihn reallocnach Bedarf. Aber das hilft Ihnen recvleider nicht bei einer UDP-Quelle.

Für SOCK_STREAMSockets 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 aus, die Sie sich leisten können.

Für SOCK_DGRAMSocket erhalten Sie den passenden Teil der Wartemeldung und der Rest wird verworfen. Sie können die Größe des wartenden Datagramms mit dem folgenden ioctl erhalten:

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

Alternativ können Sie MSG_PEEKund MSG_TRUNCFlags des recv()Aufrufs verwenden, um die Größe des wartenden Datagramms zu erhalten.

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

Sie müssen MSG_PEEKdie wartende Nachricht einsehen (nicht empfangen) - recv gibt die tatsächliche, nicht abgeschnittene Größe zurück. und Sie müssen MSG_TRUNCIhren aktuellen Puffer nicht überlaufen lassen.

Dann können Sie nur malloc(size)den realen Puffer und das recv()Datagramm.

Es gibt keine absolute Antwort auf Ihre Frage, da die Technologie 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.

Gemäß 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 Byte (~ 64 KB).

Es können jedoch nicht alle großen Pakete ordnungsgemäß von Netzwerkgeräten weitergeleitet werden. Weitere Informationen finden Sie in der vorhandenen 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 eine Größe von 9 KB haben.