Jak duży powinien być mój bufor recv podczas wywoływania recv w bibliotece gniazd

Mam kilka pytań dotyczących biblioteki gniazd w C. Oto fragment kodu, do którego będę się odnosić w moich pytaniach.

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

1. Jak zdecydować, jak duży ma być plik recv_buffer? Używam 3000, ale to arbitralne.
2. co się stanie, jeśli recv()otrzyma pakiet większy niż mój bufor?
3. Skąd mam wiedzieć, czy otrzymałem całą wiadomość bez ponownego wywoływania recv i czy czekam w nieskończoność, gdy nie ma nic do odebrania?
4. Czy jest sposób, aby bufor nie miał określonej ilości miejsca, tak żebym mógł dodawać do niego dane bez obawy, że zabraknie miejsca? może za pomocą strcatkonkatenacji najnowszej recv()odpowiedzi do bufora?

Wiem, że to wiele pytań w jednym, ale byłbym bardzo wdzięczny za wszelkie odpowiedzi.

Odpowiedzi na te pytania różnią się w zależności od tego, czy korzystasz z gniazda strumieniowego ( SOCK_STREAM), czy gniazda datagramowego ( SOCK_DGRAM) - w ramach protokołu TCP / IP pierwsze odpowiada TCP, a drugie UDP.

Skąd wiesz, do jakiej wielkości należy przekazać bufor recv()?

• SOCK_STREAM: To naprawdę nie ma większego znaczenia. Jeśli twój protokół jest protokołem transakcyjnym / interaktywnym, po prostu wybierz rozmiar, który może pomieścić największą pojedynczą wiadomość / polecenie, jakiego można by się spodziewać (3000 jest prawdopodobnie w porządku). Jeśli twój protokół przesyła dane masowo, większe bufory mogą być bardziej wydajne - dobra zasada jest taka sama, jak rozmiar bufora odbioru jądra gniazda (często około 256kB).

• SOCK_DGRAM: Użyj wystarczająco dużego bufora, aby pomieścić największy pakiet, jaki kiedykolwiek wysłał Twój protokół na poziomie aplikacji. Jeśli używasz UDP, generalnie protokół na poziomie aplikacji nie powinien wysyłać pakietów większych niż około 1400 bajtów, ponieważ z pewnością będą musiały zostać pofragmentowane i ponownie złożone.

Co się stanie, jeśli recvpakiet będzie większy niż bufor?

• SOCK_STREAM: Pytanie tak naprawdę nie ma sensu, ponieważ gniazda strumieniowe nie mają pojęcia pakietów - są one po prostu ciągłym strumieniem bajtów. Jeśli dostępnych jest więcej bajtów do odczytania, niż ma miejsce w buforze, zostaną one umieszczone w kolejce przez system operacyjny i dostępne do następnego wywołania recv.

• SOCK_DGRAM: Nadmiarowe bajty są odrzucane.

Skąd mam wiedzieć, czy otrzymałem całą wiadomość?

• SOCK_STREAM: Musisz zbudować jakiś sposób określania końca wiadomości w protokole na poziomie aplikacji. Zwykle jest to albo przedrostek długości (rozpoczynający każdą wiadomość od jej długości) lub ogranicznik końca wiadomości (który może być na przykład znakiem nowej linii w protokole tekstowym). Trzecią, rzadziej używaną opcją jest ustalenie stałego rozmiaru każdej wiadomości. Możliwe są również kombinacje tych opcji - na przykład nagłówek o stałym rozmiarze, który zawiera wartość długości.

• SOCK_DGRAM: Pojedyncze recvwywołanie zawsze zwraca pojedynczy datagram.

Czy istnieje sposób, aby bufor nie miał ustalonej ilości miejsca, aby móc dodawać do niego dane bez obawy, że zabraknie miejsca?

Nie. Możesz jednak spróbować zmienić rozmiar bufora za pomocą realloc()(jeśli pierwotnie przydzielono go za pomocą malloc()lub calloc()).

W przypadku protokołów przesyłania strumieniowego, takich jak TCP, możesz prawie ustawić bufor na dowolny rozmiar. To powiedziawszy, zalecane są wspólne wartości, które są potęgami 2, takie jak 4096 lub 8192.

Jeśli jest więcej danych niż twój bufor, zostanie po prostu zapisany w jądrze do następnego wywołania recv.

Tak, możesz dalej zwiększać swój bufor. Możesz zrobić recv do środka bufora, zaczynając od offsetu idx, zrobiłbyś:

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

Jeśli masz SOCK_STREAMgniazdo, recvpobiera po prostu „do pierwszych 3000 bajtów” ze strumienia. Nie ma jasnych wskazówek, jak duży jest bufor: jedyny moment, w którym wiesz, jak duży jest strumień, to koniec ;-).

Jeśli masz SOCK_DGRAMgniazdo, a datagram jest większy niż bufor, recvwypełnia bufor pierwszą częścią datagramu, zwraca -1 i ustawia errno na EMSGSIZE. Niestety, jeśli protokołem jest UDP, oznacza to utratę reszty datagramu - po części dlatego UDP nazywa się protokołem zawodnym (wiem, że istnieją niezawodne protokoły datagramowe, ale nie są one zbyt popularne - nie mogłem nazwij jeden z rodziny TCP / IP, pomimo tego, że dobrze go znam ;-).

Aby dynamicznie powiększyć bufor, przydziel go początkowo za pomocą malloci używaj reallocw razie potrzeby. Ale to nie pomoże ci ze recvźródła UDP, niestety.

W przypadku SOCK_STREAMgniazda rozmiar bufora tak naprawdę nie ma znaczenia, ponieważ pobierasz tylko część oczekujących bajtów i możesz pobrać więcej w następnym wywołaniu. Po prostu wybierz dowolny rozmiar bufora, na jaki Cię stać.

W przypadku SOCK_DGRAMgniazda otrzymasz pasującą część wiadomości oczekującej, a reszta zostanie odrzucona. Możesz uzyskać rozmiar oczekującego datagramu za pomocą następującego ioctl:

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

Alternatywnie można użyć MSG_PEEKi MSG_TRUNCflagi recv()wezwanie do uzyskania wielkości oczekujących datagramów.

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

Musisz MSG_PEEKzajrzeć (nie odebrać) oczekującej wiadomości - recv zwraca rzeczywisty, nie obcięty rozmiar; i nie musisz MSG_TRUNCprzepełniać obecnego bufora.

Wtedy możesz tylko malloc(size)prawdziwy bufor i recv()datagram.

Nie ma absolutnej odpowiedzi na twoje pytanie, ponieważ technologia zawsze musi być związana z konkretną implementacją. Zakładam, że komunikujesz się w protokole UDP, ponieważ rozmiar bufora przychodzącego nie powoduje problemów w komunikacji TCP.

Zgodnie z RFC 768 , rozmiar pakietu (łącznie z nagłówkiem) dla UDP może wynosić od 8 do 65 515 bajtów. Tak więc rozmiar odporny na awarie dla bufora przychodzącego wynosi 65 507 bajtów (~ 64 KB)

Jednak nie wszystkie duże pakiety mogą być prawidłowo trasowane przez urządzenia sieciowe. Więcej informacji można znaleźć w istniejącej dyskusji:

Jaki jest optymalny rozmiar pakietu UDP dla maksymalnej przepustowości?
Jaki jest największy rozmiar bezpiecznego pakietu UDP w Internecie

16kb ma rację; jeśli używasz gigabitowej sieci Ethernet, każdy pakiet może mieć rozmiar 9 kb.