Здравствуйте, уважаемый netch80, Вы писали:

AG>2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта

N>Имеется в виду вариант типа такого:
N>вызвали recv() — пришло, например, 1460 байт (типовой MSS на Ethernet без timestamp-опций).
N>Из них 1458 — первое сообщение с заголовком длины. А ещё 2 — начало заголовка длины второго сообщения.
N>Теперь надо эти 2 сохранить, ответ следующего recv() дописать к ним и уже тогда декодировать длину.

Как я уже упоминал: следующий блок (пакет пользовательского уровня) — у нас ждёт.
Ждёт, пока не отработает предшествующий пакет. Так я задумал и реализовал протокол верхнего (прикладного) уровня.
Посему, указанная Вами, уважаемый netch80, ситуация (с двумя байтами от нового блока) невозможна впринцыпе.

Да, я не использовал все возможности TCP (потоковые возможности).

Но от системы не требуется гонять (порно)фильмы, чтобы хоть как-то избежать простоя канала

Здравствуйте, уважаемый netch80, Вы писали:

AG>2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта

N>Имеется в виду вариант типа такого:
N>вызвали recv() — пришло, например, 1460 байт (типовой MSS на Ethernet без timestamp-опций).
N>Из них 1458 — первое сообщение с заголовком длины. А ещё 2 — начало заголовка длины второго сообщения.
N>Теперь надо эти 2 сохранить, ответ следующего recv() дописать к ним и уже тогда декодировать длину.

Как я уже упоминал: следующий блок (пакет пользовательского уровня) — у нас ждёт.
Ждёт, пока не отработает предшествующий пакет. Так я задумал и реализовал протокол верхнего (прикладного) уровня.
Посему, указанная Вами, уважаемый netch80, ситуация (с двумя байтами от нового блока) невозможна в принцыпе.

Да, я в курсе — что не использовал все возможности TCP. А именно — потоковые возможности.

Но от системы не требуется гонять (порно)фильмы, чтобы хоть как-то избежать простоя канала