Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   подписка   модер. 
От: avp_ 
Дата: 23.10.07 10:06
Программы обмениваются сообщениями через TCP. Сообщения короткие,
с десяток байт. Возможно ли такое что на принимающей стороне
recv вернёт меньшее количество байт чем размер сообщения?
Posted via RSDN NNTP Server 2.1 beta
Re: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: _pk_sly 
Дата: 23.10.07 10:08
_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

да
Re: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: DOOM 
Дата: 23.10.07 10:41
Здравствуйте, avp_, Вы писали:

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

Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы.
Re[2]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: _pk_sly 
Дата: 23.10.07 10:47
Здравствуйте, DOOM, Вы писали:

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

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

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

неправильно.
они могут быть буферизованы, а после этого уже фрегментированы.
Re[3]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: DOOM 
Дата: 23.10.07 11:02
Здравствуйте, _pk_sly, Вы писали:

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

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

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

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

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

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

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

Re[2]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: avp_ 
Дата: 23.10.07 11:11
DOOM wrote:

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

Ну допустим настройки сокета по умолчанию. Какова тогда возможная
причина фрагментации? Когда в буфер не помещается целое количество
сообщений?
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: DOOM 
Дата: 23.10.07 11:32
Здравствуйте, avp_, Вы писали:


_>DOOM wrote:

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

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

Причина в MTU — т.е. во втором уровне модели OSI. Ты не знаешь заранее размер MTU на каждом участке между источником и приемником — где-нибудь по дороге разобьют на части...
Re[4]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: _pk_sly 
Дата: 23.10.07 11:41
DOO>>>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы.

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

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

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

ещё бывают свичи, роутеры, тунели и т.д.
Re[4]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: avp_ 
Дата: 23.10.07 11:55
DOOM wrote:

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

MTU как я понимаю будет иметь значение если скорость отправки сообщений
будет ниже скорости их поступения. И например в случае протокола
с ожиданием ответа на каждое сообщение фрагментации быть не должно...
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: DOOM 
Дата: 23.10.07 12:00
Здравствуйте, _pk_sly, Вы писали:


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

Пойду по порядку:
свитч (классический) ничего не знает про IP, а на канальном уровне фрагментации нет.
роутер — по определению такой фигней не занимается. Фрагментация может быть только если уменьшилось MTU, ну я упомянул про 576 байт — минимальное MTU по RFC.
туннель (видимо IPsec имеется ввиду, иначе предыдущий случай) — если фрагментация произошла, после добавления нового заголовка, то пакет не будет расшифрован, если принимающая сторона не соберет все фрагменты. Если фрагменты не соберутся, то пакет будет отброшен — это опять же по RFC.
Re[5]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: DOOM 
Дата: 23.10.07 12:07
Здравствуйте, avp_, Вы писали:



_>DOOM wrote:

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

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

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

Ок. Значит посылаешь ты данные в сокет, они попадают в реализацию TCP, накручивается TCP заголовок и данные идут по конвееру на уровень IP — там, кроме накручивания заголовка, происходит еще процесс маршрутизации, в ходе которого определяется через какой интерфейс надо отправить пакет. С каждым интерфейсом в системе ассоциировано число — MTU (Max Transfer Unit) — это максимальный размер фрэйма для канального уровня данного интерфейса. В том случае, если размер IP пакета с заголовком превышает это самое MTU, то и происходит фрагментация. Буфер здесь есть на уровне сокета (точнее протокола TCP), вырубается он опцией TCP_NODELAY (если я правильно помню — если что смотри справку).
MTU для Ethernet, например 1512 байт.
Re[3]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Michael Chelnokov 
Дата: 23.10.07 12:31
Оценка: +2
Здравствуйте, avp_, Вы писали:

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

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

Вообще, рассчитывать на то что один recv в TCP вернет тебе одно сообщение — это в корне неверно. Первый же человек тебе ответил утвердительно на твой вопрос и он был прав.
Best regards,
Michael Chelnokov.
Re: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: TarasCo 
Дата: 23.10.07 12:40
Вы словом "фрагментация" всех запутали
Фрагментируются ip датаграммы. И этот процесс не зависит от работы TCP. Например, Вы можете отправить через ТСР 1000 байт. На уровне ip он могут быть фргаментированы на две датаграммы. Но на другом конце их дефрагментируют совершенно прозрачно для транспортного протокола и TCP получит порцию данных в 1000 байт. Тем не менее, это никак не гарантирует, что через ТСР данные пересылаются такими же порциями, как вы хотите вызывая функцию send. Во-первых, ТСР может собирать мелкие пакеты в более крупные ( т.н алгоритм Нагла, он отслючается опцией TCP_NODELAY ). Во-вторых, во время установки соединения оговаривается величина MSS — максимальный размер данных, пересылаемых за одну посылку ( 1460 для ethernet ). В третьих, TCP синхронизирует размер приемного окна и удаленная сторона может потребовать уменьшить окно, что может в принципе привести к уменьшению размера пересылаемых данных ( врядли это можно увидеть в современном мире ). В четвертых, на пути следования могут оказаться различные узлы вроде NAT ов, фаерволов, VPN, которые в общем случае могут пересобирать поток данных и пересылать его дальше другими порциями. Короче говоря, полагаться на то, что на приемном конце данные будут приняты такими же порциями, что и отправлялись нельзя. Нужно сразу уяснить — TCP протокол, в отличии от UDP — датаграммного протокола.
Да пребудет с тобою сила
Re[6]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: avp_ 
Дата: 23.10.07 12:43
DOOM wrote:

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

Спасибо, это всё понятно. Включаем TCP_NODELAY и совершаем посылки
меньше 576 байт. Тогда пакеты фрагментироваться не будут. Но ещё
вопрос к приёмной стороне — будет ли recv выдавать только целые
сообщения в этом случае?
Posted via RSDN NNTP Server 2.1 beta
Re[7]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: DOOM 
Дата: 23.10.07 12:46
Здравствуйте, 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 — протокол для передачи потока данных.
Re: Вероятность фрагментации посылок в избранное  msdn  новое    модер. 
От: Аноним 12 
Дата: 23.10.07 12:47
впадла добавить в начало данных один-два байта для длины последующего сообщения?
Re[2]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: avp_ 
Дата: 23.10.07 13:29
Аноним 12 wrote:
> впадла добавить в начало данных один-два байта для длины последующего сообщения?

Сообщения все фиксированной длины. Вопрос в том нужно делать
накопительный буфер и в нём собирать сообщения из кусочков.
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: _pk_sly 
Дата: 23.10.07 13:39
>> впадла добавить в начало данных один-два байта для длины последующего сообщения?

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

да.
накапливать можешь прямо в том месте, где будешь использовать.
если размер всегда одинаковый, очевидно, его можно не передавать.
Re: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: _pk_sly 
Дата: 23.10.07 13:43
_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

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

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

пожалуй, его надо задавать на собеседованиях
Re[2]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: TarasCo 
Дата: 23.10.07 13:53
__>пожалуй, его надо задавать на собеседованиях

Ну и кто прошел?
Да пребудет с тобою сила
Re[3]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Michael Chelnokov 
Дата: 23.10.07 14:27
Здравствуйте, TarasCo, Вы писали:

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

А главное — куда...
Best regards,
Michael Chelnokov.
Re[4]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: TarasCo 
Дата: 23.10.07 14:43
MC>А главное — куда...

Главное — сколько будут платить и какие подводные камни
Да пребудет с тобою сила
Re[3]: Вероятность фрагментации посылок в избранное  msdn  новое    модер. 
От: Аноним 844 
Дата: 23.10.07 17:14
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;
}

делов-то
Re[8]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: dmitriy_k 
Дата: 21.12.07 06:53
Здравствуйте, 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
Re[9]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Изя Рнет 
Дата: 23.12.07 13:40
Здравствуйте, 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.

Re: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Maxim S. Shatskih mvp 
Дата: 25.12.07 14:41
Оценка: +1
_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

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

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

На UDP этой проблемы нет, и не нужно тратить RTT на коннект, но на UDP нет и гарантии доставки, и гарантии порядка доставки, там свои радости.
Занимайтесь LoveCraftом, а не WarCraftом!
Re: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: Maxim S. Shatskih mvp 
Дата: 25.12.07 14:42
_>Программы обмениваются сообщениями через TCP. Сообщения короткие,
_>с десяток байт. Возможно ли такое что на принимающей стороне
_>recv вернёт меньшее количество байт чем размер сообщения?

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

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

На UDP этой проблемы нет, и не нужно тратить RTT на коннект, но на UDP нет и гарантии доставки, и гарантии порядка доставки, там свои радости.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[2]: Вероятность фрагментации посылок в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: remarkhttp://groups.google.com/group/lock-free
Дата: 30.12.07 18:34
Здравствуйте, Maxim S. Shatskih, Вы писали:

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


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


Всё о параллелизме. На русском.
Re: SCTP :super: в избранное  msdn  новое    Оценить +1123x:) +-   модер. 
От: remarkhttp://groups.google.com/group/lock-free
Дата: 30.12.07 18:43
Оценка:2 (1) +1
Здравствуйте, avp_, Вы писали:

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


SCTP


FeatureTCPUDPSCTP
Connection orientedYesNoYes
Reliable transportYesNoYes
Preserve message boundaryNoYesYes
Ordered deliveryYesNoYes
Unordered deliveryNoYesYes
Data checksumYesYesYes
Checksum size (bits)161632
Path MTUYesNoYes
Congestion controlYesNoYes
Multiple streamsNoNoYes
Multi-homing supportNoNoYes
BundlingNoNoYes
Всё о параллелизме. На русском.