чтение из сокета tcp/ip

если ты отправил 4 байта, то ты их получишь, возможно фрагментами по 1 байту, но ты их получишь в любом случае, если используется тсп.

Если та сторона, которая отсылает эти байты будет делать это не одним вызовом send(), а несколькими, то вполне вероятно, что может быть такая ситуация, когда придёт только часть. Если же одним вызовом, то они будут в одном пакете.

Вообще, теоретически минимальная днина данных в IP-пакете 20 байт.

ну это ясно, но это сугубо теоретический взгляд на дело! неужели ОС стоит высылать (40+1)*4 вместо (40+4), при минимальном хедере в, скажем, 40 байт?

высылается 4 байта ОДНИМ сендом

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

Например когда я смотрю ЛОР, а канал сильно загружен, то сквид иногда отдает по 1-2 байта в секунду. Как такой ответ, подходит под твой вопрос?

> если ты отправил 4 байта, то ты их получишь, возможно фрагментами по 1 байту, но ты их получишь в любом случае, если используется тсп. anonymous (*) (14.03.2006 22:44:45)

Интересно, по воздуху ты их получишь, если тебе сетевой шнур выдернуть? "Гарантированность доставки в tcp" это немного не то, что подразумевается под "гарантированностью" в обыденном смысле.

TCP-протокол прекрасно шлет и по одному байту данных, пример: telnet. Соотношение размеров заголовка и данных здесь вообще нипричем.

man 2 recv

MSG_WAITALL

Тебе этого никто не гарантирует, даже если в буфере Ос будут все 4 байта или больше вернуть recv может меньше, вроде это ни в каких стандартах не оговорено..

Скорее всего ты сразу получишь все в одном пакете, но попробуй еще алгоритм нагла отключить на сервере/клиенте. Хотя имхо это дурацкая идея просто читай в цикле пока все 4 байта не получишь и не заморачивайся ))

хотя аноним прав, MSG_WAITALL тебе может помочь..

Тебе это чисто теоретически интересно, или нет? ))

о! спасибо!

>Тебе это чисто теоретически интересно, или нет? ))

чисто теоретически. :)