| 1 2 |
| Вероятность фрагментации посылок | |
 | От: | avp_ | |
| Дата: | 23.10.07 09:06 |
| Программы обмениваются сообщениями через TCP. Сообщения короткие, с десяток байт. Возможно ли такое что на принимающей стороне recv вернёт меньшее количество байт чем размер сообщения? Posted via RSDN NNTP Server 2.1 beta |
| Re: Вероятность фрагментации посылок | |
 | От: | _pk_sly | |
| Дата: | 23.10.07 09:08 |
| _>Программы обмениваются сообщениями через TCP. Сообщения короткие, _>с десяток байт. Возможно ли такое что на принимающей стороне _>recv вернёт меньшее количество байт чем размер сообщения? да |
| Re: Вероятность фрагментации посылок | |
 | От: | DOOM | |
| Дата: | 23.10.07 09:41 |
| Здравствуйте, avp_, Вы писали: _>Программы обмениваются сообщениями через TCP. Сообщения короткие, _>с десяток байт. Возможно ли такое что на принимающей стороне _>recv вернёт меньшее количество байт чем размер сообщения? Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы. |
| Re[2]: Вероятность фрагментации посылок | |
| От: | _pk_sly | |
| Дата: | 23.10.07 09:47 |
| Здравствуйте, DOOM, Вы писали: DOO>Здравствуйте, avp_, Вы писали: _>>Программы обмениваются сообщениями через TCP. Сообщения короткие, _>>с десяток байт. Возможно ли такое что на принимающей стороне _>>recv вернёт меньшее количество байт чем размер сообщения? DOO>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы. неправильно. они могут быть буферизованы, а после этого уже фрегментированы. |
| Re[3]: Вероятность фрагментации посылок | |
| От: | DOOM | |
| Дата: | 23.10.07 10:02 |
| Здравствуйте, _pk_sly, Вы писали: __>Здравствуйте, DOOM, Вы писали: DOO>>Здравствуйте, avp_, Вы писали: _>>>Программы обмениваются сообщениями через TCP. Сообщения короткие, _>>>с десяток байт. Возможно ли такое что на принимающей стороне _>>>recv вернёт меньшее количество байт чем размер сообщения? DOO>>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы. __>неправильно. __>они могут быть буферизованы, а после этого уже фрегментированы. Читаем-то только последнее предложение?
|
| Re[2]: Вероятность фрагментации посылок | |
| От: | avp_ | |
| Дата: | 23.10.07 10:11 |
| DOOM wrote: > Если у тебя отключена буферизация на стороне отправителя, то > фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 > байт не могут быть фрагментированы. Ну допустим настройки сокета по умолчанию. Какова тогда возможная причина фрагментации? Когда в буфер не помещается целое количество сообщений? Posted via RSDN NNTP Server 2.1 beta |
| Re[3]: Вероятность фрагментации посылок | |
| От: | DOOM | |
| Дата: | 23.10.07 10:32 |
| Здравствуйте, avp_, Вы писали: _>DOOM wrote: >> Если у тебя отключена буферизация на стороне отправителя, то >> фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 >> байт не могут быть фрагментированы. _>Ну допустим настройки сокета по умолчанию. Какова тогда возможная _>причина фрагментации? Когда в буфер не помещается целое количество _>сообщений? Причина в MTU — т.е. во втором уровне модели OSI. Ты не знаешь заранее размер MTU на каждом участке между источником и приемником — где-нибудь по дороге разобьют на части... |
| Re[4]: Вероятность фрагментации посылок | |
| От: | _pk_sly | |
| Дата: | 23.10.07 10:41 |
| DOO>>>Если у тебя отключена буферизация на стороне отправителя, то фрагментации точно не будет — по стандарту IP пакеты размеров <= 576 байт не могут быть фрагментированы. __>>неправильно. __>>они могут быть буферизованы, а после этого уже фрегментированы. DOO>Читаем-то только последнее предложение? я разве написал что-то про буферизафию на стороне отправителя? ещё бывают свичи, роутеры, тунели и т.д. |
| Re[4]: Вероятность фрагментации посылок | |
| От: | avp_ | |
| Дата: | 23.10.07 10:55 |
| DOOM wrote: > Причина в MTU — т.е. во втором уровне модели OSI. Ты не знаешь заранее > размер MTU на каждом участке между источником и приемником — где-нибудь > по дороге разобьют на части... MTU как я понимаю будет иметь значение если скорость отправки сообщений будет ниже скорости их поступения. И например в случае протокола с ожиданием ответа на каждое сообщение фрагментации быть не должно... Posted via RSDN NNTP Server 2.1 beta |
| Re[5]: Вероятность фрагментации посылок | |
| От: | DOOM | |
| Дата: | 23.10.07 11:00 |
| Здравствуйте, _pk_sly, Вы писали: __>ещё бывают свичи, роутеры, тунели и т.д. Пойду по порядку: свитч (классический) ничего не знает про IP, а на канальном уровне фрагментации нет. роутер — по определению такой фигней не занимается. Фрагментация может быть только если уменьшилось MTU, ну я упомянул про 576 байт — минимальное MTU по RFC. туннель (видимо IPsec имеется ввиду, иначе предыдущий случай) — если фрагментация произошла, после добавления нового заголовка, то пакет не будет расшифрован, если принимающая сторона не соберет все фрагменты. Если фрагменты не соберутся, то пакет будет отброшен — это опять же по RFC. |
| Re[5]: Вероятность фрагментации посылок | |
| От: | DOOM | |
| Дата: | 23.10.07 11: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]: Вероятность фрагментации посылок | |
 | От: | Michael Chelnokov | |
| Дата: | 23.10.07 11:31 | ||
| Оценка: | +2 | ||
| Здравствуйте, avp_, Вы писали: _>Когда в буфер не помещается целое количество сообщений? А почему бы и нет? Вообще, рассчитывать на то что один recv в TCP вернет тебе одно сообщение — это в корне неверно. Первый же человек тебе ответил утвердительно на твой вопрос и он был прав. Best regards, Michael Chelnokov. |
| Re: Вероятность фрагментации посылок | |
 | От: | TarasCo | |
| Дата: | 23.10.07 11:40 |
Вы словом "фрагментация" всех запутали  Фрагментируются ip датаграммы. И этот процесс не зависит от работы TCP. Например, Вы можете отправить через ТСР 1000 байт. На уровне ip он могут быть фргаментированы на две датаграммы. Но на другом конце их дефрагментируют совершенно прозрачно для транспортного протокола и TCP получит порцию данных в 1000 байт. Тем не менее, это никак не гарантирует, что через ТСР данные пересылаются такими же порциями, как вы хотите вызывая функцию send. Во-первых, ТСР может собирать мелкие пакеты в более крупные ( т.н алгоритм Нагла, он отслючается опцией TCP_NODELAY ). Во-вторых, во время установки соединения оговаривается величина MSS — максимальный размер данных, пересылаемых за одну посылку ( 1460 для ethernet ). В третьих, TCP синхронизирует размер приемного окна и удаленная сторона может потребовать уменьшить окно, что может в принципе привести к уменьшению размера пересылаемых данных ( врядли это можно увидеть в современном мире  ). В четвертых, на пути следования могут оказаться различные узлы вроде NAT ов, фаерволов, VPN, которые в общем случае могут пересобирать поток данных и пересылать его дальше другими порциями. Короче говоря, полагаться на то, что на приемном конце данные будут приняты такими же порциями, что и отправлялись нельзя. Нужно сразу уяснить — TCP протокол, в отличии от UDP — датаграммного протокола.Да пребудет с тобою сила |
| Re[6]: Вероятность фрагментации посылок | |
| От: | avp_ | |
| Дата: | 23.10.07 11: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]: Вероятность фрагментации посылок | |
| От: | DOOM | |
| Дата: | 23.10.07 11:46 |
| Здравствуйте, avp_, Вы писали: _>DOOM wrote: >> Ок. Значит посылаешь ты данные в сокет, они попадают в реализацию TCP, >> накручивается TCP заголовок и данные идут по конвееру на уровень IP - >> там, кроме накручивания заголовка, происходит еще процесс маршрутизации, >> в ходе которого определяется через какой интерфейс надо отправить пакет. >> С каждым интерфейсом в системе ассоциировано число — MTU (Max Transfer >> Unit) — это максимальный размер фрэйма для канального уровня данного >> интерфейса. В том случае, если размер IP пакета с заголовком превышает >> это самое MTU, то и происходит фрагментация. Буфер здесь есть на уровне >> сокета (точнее протокола TCP), вырубается он опцией TCP_NODELAY (если я >> правильно помню — если что смотри справку). MTU для Ethernet, например >> 1512 байт. _>Спасибо, это всё понятно. Включаем TCP_NODELAY и совершаем посылки _>меньше 576 байт. Тогда пакеты фрагментироваться не будут. Но ещё _>вопрос к приёмной стороне — будет ли recv выдавать только целые _>сообщения в этом случае? А вот про это тебе уже сказал Автор: TarasCo TarasCo.Дата: 23.10.07 В общем случае для пересылки сообщений (до бишь датаграм) надо и использовать протокол, который шлет сообщения. TCP — протокол для передачи потока данных. |
| Re: Вероятность фрагментации посылок | |
 | От: | Аноним 12 | |
| Дата: | 23.10.07 11:47 |
| впадла добавить в начало данных один-два байта для длины последующего сообщения? |
| Re[2]: Вероятность фрагментации посылок | |
| От: | avp_ | |
| Дата: | 23.10.07 12:29 |
| Аноним 12 wrote: > впадла добавить в начало данных один-два байта для длины последующего сообщения? Сообщения все фиксированной длины. Вопрос в том нужно делать накопительный буфер и в нём собирать сообщения из кусочков. Posted via RSDN NNTP Server 2.1 beta |
| Re[3]: Вероятность фрагментации посылок | |
| От: | _pk_sly | |
| Дата: | 23.10.07 12:39 |
| >> впадла добавить в начало данных один-два байта для длины последующего сообщения? _>Сообщения все фиксированной длины. Вопрос в том нужно делать _>накопительный буфер и в нём собирать сообщения из кусочков. да. накапливать можешь прямо в том месте, где будешь использовать. если размер всегда одинаковый, очевидно, его можно не передавать. |
| Re: Вероятность фрагментации посылок | |
| От: | _pk_sly | |
| Дата: | 23.10.07 12:43 |
| _>Программы обмениваются сообщениями через TCP. Сообщения короткие, _>с десяток байт. Возможно ли такое что на принимающей стороне _>recv вернёт меньшее количество байт чем размер сообщения? очень показательный вопрос. по ответам видно, кто только читал теорию, а кто хоть раз попытался что-то отправить или принять по сети  пожалуй, его надо задавать на собеседованиях |
| Re[2]: Вероятность фрагментации посылок | |
| От: | TarasCo | |
| Дата: | 23.10.07 12:53 |
| __>пожалуй, его надо задавать на собеседованиях Ну и кто прошел? Да пребудет с тобою сила |
| 1 2 |