Всё там прекрасно указано!

If no error occurs, recv returns the number of bytes received and the buffer pointed to by the buf parameter will contain this data received. If the connection has been gracefully closed, the return value is zero.
Otherwise, a value of SOCKET_ERROR is returned, and a specific error code can be retrieved by calling WSAGetLastError.

SOCKET_ERROR это -1. Так что ты любую ошибку воспримешь как "нет новых данных". Различить можно по WSAGetLastError() и скорее всего, это будет WSAEWOULDBLOCK.

А вообще,
> Как же проверить, сколько байт пришло? А для этого есть специальный флаговый параметр
Для этого есть ioctlsocket(FIONREAD), но и он, и PEEK, и select() в лучшем случае гарантируют тебе "что-то пришло", а не точный объём данных.

Там всё устроено примерно так. У TCP есть внутри небольшой буфер, куда он складывает прилетающие байты. И он сообщает отправителю, сколько он ещё готов принимать. Когда буфер заполняется, он говорит стопэ, и отправитель подвисает в своём блокирующем send().
Вот если у тебя сообщение больше этого буфера, ты его одним махом никогда не получишь.

Только два способа разбирать TCP надёжно:
1. Создать буфер нужного размера, передать его в winsock и смиренно ждать, когда его заполнят. (винсок сам будет вынимать байты в твой буфер по мере поступления)
2. Немедленно вынимать из recv() всё, что там становится доступным, и класть в свой собственный буфер, который уже разбирать как тебе нравится.

Второе сделать можно кучей способов: peek + recv (неэффективно: читаешь дважды), FIONREAD+recv (норм), select+FIONREAD+recv (чтобы эффективно спать, пока ничего нет), включить неблокирующие сокеты и пробовать время от времени (плохо), включить неблокирующие сокеты и спать на эвенте, включить неблокирующие сокеты и получать оконные события, включить неблокирующие сокеты и делать overlapped (ты запустил чтение и тебе скажут, когда оно сделалось).

Из всего этого overlapped это самое эффективное, поскольку ты по сути пульнул заявку в режим ядра и ушёл по своим делам, но оно нужно только при сотнях подключений. А самое простое это висеть в recv намертво, если у тебя отдельный поток, а когда поток надо завершать, то сказать ему снаружи crash and burn ( closesocket() + WSACancelBlockingCall() )

himself, ультимативный гайд, спасибо!

Мммм, сколько здесь знатоков... =)

А я был уверен что tcp передаёт непрерывный поток байт и вот такая постановка вопроса в принципе не верна:
> Вот если у тебя сообщение больше этого буфера, ты его одним махом никогда не получишь.

Это же как читать файл или пайп. ХЗ сколько там ещё байт, никто ничего не гарантирует.

Xersareeth, рад, что помог узнать что-то новое

Вот ещё полезная ссылка.

Эээ, а как tcp может передавать непрерывный поток байт, если там при этом идет проверка контрольных сумм и подтверждения доставки?)

deadlymercury, вероятно точно так же, как в файлах может храниться непрерывный поток байт, хотя там кластеры, секторы и чёрти-чо ещё, в том числе и проверка контрольных сумм =)

Так tcp это же гораздо более низкоуровневая штука, чем "файл"?)

Дыа? И на каком же уровне модели osi находятся файлы?)

где-то над фс, который при этом тоже менее низкоуровневая штука, чем tcp Хотя при этом tcp более высокоуровневая штука, чем сектора на диске.