Яким повинен бути буфер мого recv при виклику recv у бібліотеці сокетів

У мене є кілька запитань щодо бібліотеки сокетів у C. Ось фрагмент коду, на який я звернуся у своїх запитаннях.

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

1. Як вирішити, наскільки великим зробити recv_buffer? Я використовую 3000, але це довільно.
2. що станеться, якщо recv()отримає пакет, більший за мій буфер?
3. як я можу дізнатися, чи отримав я все повідомлення без повторного виклику recv і чи повинен він чекати вічно, коли нічого не буде отримано?
4. чи є спосіб зробити так, щоб у буфера не було фіксованої кількості місця, щоб я міг продовжувати додавати його, не боячись не вистачити місця? можливо, використовуючи strcatдля об'єднання останньої recv()відповіді на буфер?

Я знаю, що це багато питань в одному, але я дуже вдячний за будь-які відповіді.

Відповіді на ці запитання різняться залежно від того, використовуєте ви потоковий socket ( SOCK_STREAM) або socket дейтаграми ( SOCK_DGRAM) - в TCP / IP, перший відповідає TCP, а другий - UDP.

Звідки ви знаєте, наскільки великим є перехід на буфер recv()?

• SOCK_STREAM: Це насправді не має великого значення. Якщо ваш протокол є транзакційним / інтерактивним, просто виберіть розмір, який може містити найбільше індивідуальне повідомлення / команду, якого ви могли б очікувати (3000, ймовірно, добре). Якщо ваш протокол передає об'ємні дані, то більші буфери можуть бути ефективнішими - добре правило великого розміру приблизно таке ж, як розмір буфера ядра сокету (часто це щось близько 256 кБ).

• SOCK_DGRAM: Використовуйте буфер, достатньо великий, щоб вмістити найбільший пакет, який коли-небудь надсилає ваш протокол рівня програми. Якщо ви використовуєте UDP, то, як правило, ваш протокол на рівні додатків не повинен надсилати пакети розміром більше 1400 байт, тому що їх, безумовно, потрібно буде фрагментувати і знову збирати.

Що станеться, якщо ви recvотримаєте пакет, більший за буфер?

• SOCK_STREAM: Питання насправді не має сенсу, як висловлюється, оскільки потокові сокети не мають поняття пакетів - вони просто суцільний потік байтів. Якщо для читання доступно більше байтів, ніж у вашому буфері, можливо, ОС буде встановлена ​​в чергу і буде доступна для наступного дзвінка recv.

• SOCK_DGRAM: Надлишки байтів відкидаються.

Як я можу дізнатися, чи отримав я все повідомлення?

• SOCK_STREAM: Вам потрібно побудувати певний спосіб визначення кінця повідомлення в протоколі рівня програми. Зазвичай це або префікс довжини (починаючи кожне повідомлення довжиною повідомлення), або обмежувач кінця повідомлення (який, наприклад, може бути лише новим рядком у текстовому протоколі). Третій варіант, що використовується менш часто, - надати фіксований розмір для кожного повідомлення. Можливі також комбінації цих параметрів - наприклад, заголовок фіксованого розміру, що включає значення довжини.

• SOCK_DGRAM: Один recvвиклик завжди повертає одну дейтаграму.

Чи є спосіб зробити так, щоб буфер не мав фіксованої кількості місця, щоб я міг продовжувати додавати його, не боячись не вистачити місця?

Ні . Тим НЕ менше, ви можете спробувати змінити розмір буфера з допомогою realloc()(якщо він був спочатку виділяється malloc()або calloc(), тобто).

Для потокових протоколів, таких як TCP, ви можете майже встановити буфер будь-якого розміру. З огляду на це, рекомендуються загальні значення, які є повноваженнями 2, наприклад 4096 або 8192.

Якщо більше даних, то який ваш буфер, він буде просто збережений у ядрі для наступного дзвінка recv.

Так, ви можете продовжувати рости буфера. Ви можете зробити реверс в середину буфера, починаючи з зміщення idx, ви б зробили:

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

Якщо у вас є SOCK_STREAMрозетка, recvпросто отримуєте "до перших 3000 байт" з потоку. Немає чітких рекомендацій щодо того, наскільки великим є буфер: єдиний раз, коли ви знаєте, наскільки великий потік, - це коли це все зроблено ;-).

Якщо у вас є SOCK_DGRAMсокет, а дейтаграма більша за буфер, recvзаповнює буфер першою частиною дейтаграми, повертає -1 і встановлює errno на EMSGSIZE. На жаль, якщо протокол є UDP, це означає, що решта дейтаграми втрачається - частина чому UDP називається ненадійним протоколом (я знаю, що є надійні протоколи дейтаграми, але вони не дуже популярні - я не міг назвіть його в родині TCP / IP, незважаючи на те, що останній досить добре знає ;-).

Щоб динамічно нарощувати буфер, виділіть його спочатку за допомогою mallocта використовуйте reallocза потребою. Але це не допоможе вам з recvджерелом UDP, на жаль.

Для SOCK_STREAMсокета розмір буфера насправді не має значення, тому що ви просто підтягуєте частину байтів, що очікують, і ви можете отримати більше в наступному дзвінку. Виберіть будь-який розмір буфера, який ви можете собі дозволити.

Для SOCK_DGRAMрозетки ви отримаєте відповідну частину повідомлення, що чекає, а решта буде відкинута. Розмір дейтаграми очікування можна отримати за допомогою наступного ioctl:

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

Крім того, ви можете використовувати MSG_PEEKі MSG_TRUNCпрапори recv()дзвінка, щоб отримати розмір дейтаграми очікування.

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

Вам потрібно MSG_PEEKзазирнути (не отримати) повідомлення очікування - recv повертає справжній, не усічений розмір; і вам не потрібно MSG_TRUNCпереповнювати поточний буфер.

Тоді ви можете просто malloc(size)справжній буфер і recv()дейтаграму.

Немає абсолютної відповіді на ваше запитання, оскільки технологія завжди повинна залежати від впровадження. Я припускаю, що ви спілкуєтесь в UDP, оскільки розмір вхідного буфера не приносить проблем TCP-зв’язку.

Відповідно до RFC 768 , розмір пакету (включно із заголовком) для UDP може становити від 8 до 65 515 байт. Отже, розмір відмов для вхідного буфера становить 65 507 байт (~ 64 КБ)

Однак не всі великі пакети можуть бути правильно маршрутизовані мережевими пристроями, для отримання додаткової інформації зверніться до існуючої дискусії:

Який оптимальний розмір пакету UDP для максимальної пропускної здатності?
Який найбільший розмір безпечного пакету UDP в Інтернеті

16kb - приблизно справа; якщо ви використовуєте гігабітну мережу, кожен пакет може бути розміром 9 кбіт.