[IP][TCP] IP-датаграммы и TCP-сегменты на приеме

1. Фрагменты должны быть собраны как и было.

2. TCP пакты должны быть восстановлены. Не совсем понятно как их можно объединить. У них-же уникальные seq-номера. Это объединяет какой-то более высокий уровень абстракции.

ну, например, какая-то особая реализация TCP-протокола, которая позволяет таким обращом уплотнять трафик для более эффективного использования канального ресурса.

значит та ситуация, с которой я столкнулся при реализации под вендой обясняется вендовой протокола?

В принципе сделать так можно, но непонятно зачем. Экономии не будет. Ведь сборка в любом случае уже после получения осуществляется. В принципе для TCP довольно логично сливать все как можно плотнее.

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

"У них-же уникальные seq-номера" Октеты нумеруются, RTFM.

Чего-то я под вечер туплю. О каких пакетах речь идет при использовании сокетов? recv (или что там в винде) принимает в качестве параметра размер данных и если сокет блокирующий, то прием заблокируется пока не наберется нужного колличества. Ни о каких пакетах речи быть не может.

При записи ОС их тоже может объединять, но такого на моей практике не встречалось. То-есть передалось по сети их 10 скорее всего. Проверить можно снифером.

А примеры реально подтвержденых работающих реализаций этой схемы есть? Накапливать можно, согласен, но кто так делает реально?

А есть ли полная уверенность, что ушло десять сегментов? Может, их два и ушло. http://en.wikipedia.org/wiki/Nagle's_algorithm

> Проверить можно снифером.

вот, здравая мысль. я до этого не додумался... завтра проверю. про тонкости виндовых сокетов не могу сказать - набыдлокодил прогу на delphi за 30 минут, используя справку и инет.

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

Да, согласен, стандартам не противоречит...

А по исходному посту вопрос: а что принималось за пакет на приемной сторне? Можно привести функцию чтения данных?

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

Есть вероятность, что сокет неблокирующий и со времением ожидания меньше 1 мс :). Все-таки код приемника увидеть-бы, тогда можно качать телепатические возможности дальше, один фиг скучно :)

исходники на работе. если честно, то сам я писал только программу для отправки данных (используется send). программу для приема писал другой человек с использованием каких-то компонент (clientsocket?). там смысл такой, что когда приходят данные, возникает событие, причем количество принятых данных хранится в какой-то переменной (точно я не помню)...

но мне интересен вариант для исполнения в железе, т. е. независимо от ОС и ее механизмов реализации. как я понял, если моя железка правильно приняла, упорядочила и собрала все IP-датаграммы, то я получу те TCP-сегменты, которые отправлял (отправка также ведется железкой)

TCP-сегменты будут однозначног те (если по пути действительно не стояло третьего устройства, которе пересобирало пакеты, но это уже 2 отдельных сегмента сети и совсем другая песня). Но то что подразумевается под сокетами - это не совсем TCP уже. Из драйвера сетевой выйдут нормальные пакеты, а что с ними дальше делать перед тем как отдать пользователю - дело ОС.

а вот про передачу через несколько сетей тоже интересно...

Хотел начать наезжать на тебя - как это ты так rfc читал, и вспомнил, что сам до чтения rfc, кроме этого читал Олифера - 3, и еще Локальные Сети(принципы практика, построение).

Просто, разные уровни, для разных вещей предназначены. От того ip - дейтаграммы а tcp - сообщения. Сокеты это вообще в другую степь - o.s.

Запусти wireshark - и все станет ясно. :)

Ответ: Да.

В TCP для клиента работающего с tcp-сокетом вообще нет разбивки на пакеты, сегменты и тп. Есть только поток данных, как на входе, так и на выходе. Размеры кусков, которыми пишет писатель и которые читает читатель могут никак не совпадать. А вот последовательность байтиков, это таки да, совпадает.

Есть хорошая книжка "Йон Снейдер Эффективное программирование TCP/IP". Она, на основе Стивенса, но проще, компактнее и занимательнее.

> возможна ли сутиация, когда переданные мной данные в виде нескольких TCP-сегментов будут "уплотнены" в меньшее количество TCP-сегментов, если позволяет MTU?

and

> Ответ: Да.

При чтении данного поста меньше всего внимания обратил на сам вопрос. Там почти все вопрос.

Возможно. tcp рассматривает информацию которую передает как поток сырых данных. sory за дубляж вышесказанного.