Программы обмениваются сообщениями через TCP. Сообщения короткие,
с десяток байт. Возможно ли такое что на принимающей стороне
recv вернёт меньшее количество байт чем размер сообщения?

_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

да

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

_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы.

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

DOO>Здравствуйте, avp_, Вы писали:

_>>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>>с десяток байт. Возможно ли такое что на принимающей стороне
_>>recv вернёт меньшее количество байт чем размер сообщения?

DOO>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы.

неправильно.
они могут быть буферизованы, а после этого уже фрегментированы.

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

__>Здравствуйте, DOOM, Вы писали:

DOO>>Здравствуйте, avp_, Вы писали:

_>>>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>>>с десяток байт. Возможно ли такое что на принимающей стороне
_>>>recv вернёт меньшее количество байт чем размер сообщения?

DOO>>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы.

__>неправильно.
__>они могут быть буферизованы, а после этого уже фрегментированы.

Читаем-то только последнее предложение?

Если у тебя отключена буферизация на стороне отправителя

DOOM wrote:

> Если у тебя отключена буферизация на стороне отправителя, то
> фрагментации точно не будет — по стандарту IP пакеты размеров <= 576
> байт не могут быть фрагментированы.

Ну допустим настройки сокета по умолчанию. Какова тогда возможная
причина фрагментации? Когда в буфер не помещается целое количество
сообщений?

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


_>DOOM wrote:

>> Если у тебя отключена буферизация на стороне отправителя, то
>> фрагментации точно не будет — по стандарту IP пакеты размеров <= 576
>> байт не могут быть фрагментированы.

_>Ну допустим настройки сокета по умолчанию. Какова тогда возможная
_>причина фрагментации? Когда в буфер не помещается целое количество
_>сообщений?

Причина в MTU — т.е. во втором уровне модели OSI. Ты не знаешь заранее размер MTU на каждом участке между источником и приемником — где-нибудь по дороге разобьют на части...

DOO>>>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы.

__>>неправильно.
__>>они могут быть буферизованы, а после этого уже фрегментированы.

DOO>Читаем-то только последнее предложение?

я разве написал что-то про буферизафию на стороне отправителя?

ещё бывают свичи, роутеры, тунели и т.д.

DOOM wrote:

> Причина в MTU — т.е. во втором уровне модели OSI. Ты не знаешь заранее
> размер MTU на каждом участке между источником и приемником — где-нибудь
> по дороге разобьют на части...

MTU как я понимаю будет иметь значение если скорость отправки сообщений
будет ниже скорости их поступения. И например в случае протокола
с ожиданием ответа на каждое сообщение фрагментации быть не должно...

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


__>ещё бывают свичи, роутеры, тунели и т.д.

Пойду по порядку:
свитч (классический) ничего не знает про IP, а на канальном уровне фрагментации нет.
роутер — по определению такой фигней не занимается. Фрагментация может быть только если уменьшилось MTU, ну я упомянул про 576 байт — минимальное MTU по RFC.
туннель (видимо IPsec имеется ввиду, иначе предыдущий случай) — если фрагментация произошла, после добавления нового заголовка, то пакет не будет расшифрован, если принимающая сторона не соберет все фрагменты. Если фрагменты не соберутся, то пакет будет отброшен — это опять же по RFC.

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



_>DOOM wrote:

>> Причина в MTU — т.е. во втором уровне модели OSI. Ты не знаешь заранее
>> размер MTU на каждом участке между источником и приемником — где-нибудь
>> по дороге разобьют на части...

_>MTU как я понимаю будет иметь значение если скорость отправки сообщений
_>будет ниже скорости их поступения. И например в случае протокола
_>с ожиданием ответа на каждое сообщение фрагментации быть не должно...

Хм... Что-то не понял я твоей фразы, но понял, что надо объяснить более подробно...

Ок. Значит посылаешь ты данные в сокет, они попадают в реализацию TCP, накручивается TCP заголовок и данные идут по конвееру на уровень IP — там, кроме накручивания заголовка, происходит еще процесс маршрутизации, в ходе которого определяется через какой интерфейс надо отправить пакет. С каждым интерфейсом в системе ассоциировано число — MTU (Max Transfer Unit) — это максимальный размер фрэйма для канального уровня данного интерфейса. В том случае, если размер IP пакета с заголовком превышает это самое MTU, то и происходит фрагментация. Буфер здесь есть на уровне сокета (точнее протокола TCP), вырубается он опцией TCP_NODELAY (если я правильно помню — если что смотри справку).
MTU для Ethernet, например 1512 байт.

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

_>Когда в буфер не помещается целое количество сообщений?

А почему бы и нет?

Вообще, рассчитывать на то что один recv в TCP вернет тебе одно сообщение — это в корне неверно. Первый же человек тебе ответил утвердительно на твой вопрос и он был прав.

Вы словом "фрагментация" всех запутали
Фрагментируются ip датаграммы. И этот процесс не зависит от работы TCP. Например, Вы можете отправить через ТСР 1000 байт. На уровне ip он могут быть фргаментированы на две датаграммы. Но на другом конце их дефрагментируют совершенно прозрачно для транспортного протокола и TCP получит порцию данных в 1000 байт. Тем не менее, это никак не гарантирует, что через ТСР данные пересылаются такими же порциями, как вы хотите вызывая функцию send. Во-первых, ТСР может собирать мелкие пакеты в более крупные ( т.н алгоритм Нагла, он отслючается опцией TCP_NODELAY ). Во-вторых, во время установки соединения оговаривается величина MSS — максимальный размер данных, пересылаемых за одну посылку ( 1460 для ethernet ). В третьих, TCP синхронизирует размер приемного окна и удаленная сторона может потребовать уменьшить окно, что может в принципе привести к уменьшению размера пересылаемых данных ( врядли это можно увидеть в современном мире ). В четвертых, на пути следования могут оказаться различные узлы вроде NAT ов, фаерволов, VPN, которые в общем случае могут пересобирать поток данных и пересылать его дальше другими порциями. Короче говоря, полагаться на то, что на приемном конце данные будут приняты такими же порциями, что и отправлялись нельзя. Нужно сразу уяснить — TCP протокол, в отличии от UDP — датаграммного протокола.

DOOM wrote:

> Ок. Значит посылаешь ты данные в сокет, они попадают в реализацию TCP,
> накручивается TCP заголовок и данные идут по конвееру на уровень IP -
> там, кроме накручивания заголовка, происходит еще процесс маршрутизации,
> в ходе которого определяется через какой интерфейс надо отправить пакет.
> С каждым интерфейсом в системе ассоциировано число — MTU (Max Transfer
> Unit) — это максимальный размер фрэйма для канального уровня данного
> интерфейса. В том случае, если размер IP пакета с заголовком превышает
> это самое MTU, то и происходит фрагментация. Буфер здесь есть на уровне
> сокета (точнее протокола TCP), вырубается он опцией TCP_NODELAY (если я
> правильно помню — если что смотри справку). MTU для Ethernet, например
> 1512 байт.

Спасибо, это всё понятно. Включаем TCP_NODELAY и совершаем посылки
меньше 576 байт. Тогда пакеты фрагментироваться не будут. Но ещё
вопрос к приёмной стороне — будет ли recv выдавать только целые
сообщения в этом случае?

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



_>DOOM wrote:

>> Ок. Значит посылаешь ты данные в сокет, они попадают в реализацию TCP,
>> накручивается TCP заголовок и данные идут по конвееру на уровень IP -
>> там, кроме накручивания заголовка, происходит еще процесс маршрутизации,
>> в ходе которого определяется через какой интерфейс надо отправить пакет.
>> С каждым интерфейсом в системе ассоциировано число — MTU (Max Transfer
>> Unit) — это максимальный размер фрэйма для канального уровня данного
>> интерфейса. В том случае, если размер IP пакета с заголовком превышает
>> это самое MTU, то и происходит фрагментация. Буфер здесь есть на уровне
>> сокета (точнее протокола TCP), вырубается он опцией TCP_NODELAY (если я
>> правильно помню — если что смотри справку). MTU для Ethernet, например
>> 1512 байт.

_>Спасибо, это всё понятно. Включаем TCP_NODELAY и совершаем посылки
_>меньше 576 байт. Тогда пакеты фрагментироваться не будут. Но ещё
_>вопрос к приёмной стороне — будет ли recv выдавать только целые
_>сообщения в этом случае?

А вот про это тебе уже сказал

Автор: TarasCo
Дата: 23.10.07

TarasCo.
В общем случае для пересылки сообщений (до бишь датаграм) надо и использовать протокол, который шлет сообщения. TCP — протокол для передачи потока данных.

впадла добавить в начало данных один-два байта для длины последующего сообщения?

Аноним 12 wrote:
> впадла добавить в начало данных один-два байта для длины последующего сообщения?

Сообщения все фиксированной длины. Вопрос в том нужно делать
накопительный буфер и в нём собирать сообщения из кусочков.

>> впадла добавить в начало данных один-два байта для длины последующего сообщения?

_>Сообщения все фиксированной длины. Вопрос в том нужно делать
_>накопительный буфер и в нём собирать сообщения из кусочков.

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

_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

очень показательный вопрос.

по ответам видно, кто только читал теорию, а кто хоть раз попытался что-то отправить или принять по сети

пожалуй, его надо задавать на собеседованиях

__>пожалуй, его надо задавать на собеседованиях

Ну и кто прошел?

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

TC>Ну и кто прошел?

А главное — куда...

MC>А главное — куда...

Главное — сколько будут платить и какие подводные камни

bool recv_fixed_length(int sc, char *buf, int len)
{
while (len>0)
 {
 int r = recv(sc, buf, len, 0);
 if (r<=0) return false;
 len -= r;
 buf += r;
 }
return true;
}

делов-то

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

_>>Спасибо, это всё понятно. Включаем TCP_NODELAY и совершаем посылки
_>>меньше 576 байт. Тогда пакеты фрагментироваться не будут. Но ещё
_>>вопрос к приёмной стороне — будет ли recv выдавать только целые
_>>сообщения в этом случае?

DOO>А вот про это тебе уже сказал

Автор: TarasCo
Дата: 23.10.07

TarasCo.
DOO>В общем случае для пересылки сообщений (до бишь датаграм) надо и использовать протокол, который шлет сообщения. TCP — протокол для передачи потока данных.
Кто сказал что требование RFC про 576 байт(строго говоря это размер Reassembly buffer а не минимальный MTU) реально _всегда_ соблюдается?
Мне встречалась рекомендация в определенных условиях (OpenVPN поверх GPRS) ставить MTU(именно MTU) 200 байт, для ускорения работы. И в тех условиях-действительно работало быстрее. Где гарантия что никто так не настроил свой стек?
p.s.в IPv6 — там есть _требование_ что минимальный MTU 1280 байт, если он меньше — это уже проблемы поддержки IPv6 для соответствующего Layer2-протокола. Не припоминаю чтото аналогичного требования в RFC про IPv4

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

_>Здравствуйте, DOOM, Вы писали:

_>>>Спасибо, это всё понятно. Включаем TCP_NODELAY и совершаем посылки
_>>>меньше 576 байт. Тогда пакеты фрагментироваться не будут. Но ещё
_>>>вопрос к приёмной стороне — будет ли recv выдавать только целые
_>>>сообщения в этом случае?

DOO>>А вот про это тебе уже сказал

Автор: TarasCo
Дата: 23.10.07

TarasCo.
DOO>>В общем случае для пересылки сообщений (до бишь датаграм) надо и использовать протокол, который шлет сообщения. TCP — протокол для передачи потока данных.
_>Кто сказал что требование RFC про 576 байт(строго говоря это размер Reassembly buffer а не минимальный MTU) реально _всегда_ соблюдается?

Reassembly buffer в 576 байт? Соблюдается всегда. Не знаю ни одной реализации, где было бы меньше.

_>Мне встречалась рекомендация в определенных условиях (OpenVPN поверх GPRS) ставить MTU(именно MTU) 200 байт, для ускорения работы. И в тех условиях-действительно работало быстрее. Где гарантия что никто так не настроил свой стек?

Какое это имеет отношение к reassembly buffer?

_>p.s.в IPv6 — там есть _требование_ что минимальный MTU 1280 байт, если он меньше — это уже проблемы поддержки IPv6 для соответствующего Layer2-протокола. Не припоминаю чтото аналогичного требования в RFC про IPv4

68 байт.

RFC791:

Every internet module must be able to forward a datagram of 68
octets without further fragmentation. This is because an internet
header may be up to 60 octets, and the minimum fragment is 8 octets.

_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

В TCP границы recv вообще никак не совпадают с границами send, т.е. вполне реальна картина, когда 1 recv вернет хвост первого сообщения, потом еще 10 сообщений и потом голову 11го.

Над TCP придется писать свою state machine, и в своем протоколе предусматривать заголовки с длиной в них, иначе никак.

На UDP этой проблемы нет, и не нужно тратить RTT на коннект, но на UDP нет и гарантии доставки, и гарантии порядка доставки, там свои радости.

_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

В TCP границы recv вообще никак не совпадают с границами send, т.е. вполне реальна картина, когда 1 recv вернет хвост первого сообщения, потом еще 10 сообщений и потом голову 11го.

Над TCP придется писать свою state machine, и в своем протоколе предусматривать заголовки с длиной в них, иначе никак.

На UDP этой проблемы нет, и не нужно тратить RTT на коннект, но на UDP нет и гарантии доставки, и гарантии порядка доставки, там свои радости.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>На UDP этой проблемы нет...


... если сообщение влазит

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

_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?


SCTP

Feature	TCP	UDP	SCTP
Connection oriented	Yes	No	Yes
Reliable transport	Yes	No	Yes
Preserve message boundary	No	Yes	Yes
Ordered delivery	Yes	No	Yes
Unordered delivery	No	Yes	Yes
Data checksum	Yes	Yes	Yes
Checksum size (bits)	16	16	32
Path MTU	Yes	No	Yes
Congestion control	Yes	No	Yes
Multiple streams	No	No	Yes
Multi-homing support	No	No	Yes
Bundling	No	No	Yes