MMU

BB>> При построении реализации TCP/IP с ограничениями в виде отсутствия BB>> сборки пакетов из фрагментов неявно предполагается, что BB>> фрагментирование в сети отсутствует. Истинность этого допущения сильно BB>> зависит от текущих сетевых технологий. Вполне возможно, что сейчас MTU BB>> в магистральных сетях больше или равен MTU в езернете. При таких BB>> условиях фрагментирование на практике будет встречаться сравнительно BB>> редко, только если пакет идет по старым сетям с маленьким MTU.

AM> Фрагментирование TCP будет встречаться достаточно редко до тех пор, AM> пока будет сохраняться повсеместное использование PMTUD. Я пока не вижу AM> причин, почему от его использования могут начать отказываться.

А вот товарищ Slav Matveev в соседнем посте умудрился на пинге получить и фрагментирование и перепутывание фрагментов. Так что проблема наличия фрагментирования существует.

AL>> Hу да, многозадачка легко подстpаивается под неопpеделенное число AL>> заpанее неизвестных задач - только это для эхотага обычно AL>> нехаpактеpно. А вот на фиксиpованном (относительно) небольшом набоpе AL>> веток пpеpывания в однозадачке ничем не хуже.

NAS> В рулинуксе периодически ходит FAQ "как писать сервера". NAS> Одна нить/задача и конечный автомат, разбирающий всё, являлся бы NAS> идеальным решением если бы не относительная сложность реализации. NAS> "по нити/Задаче на каждый чих" намного проще/быстрее писать, но при этом NAS> результат выходит жирнее по потребным ресурсам.

Нисколько не жирнее. Не знаю как там в линуксе сделано, но в нормальных системах исполняемый код общий, а ОЗУ и стек по-любому придется дублировать. Так что при нормальной вытесняющей многозадачке фактически накладные расходы это только переключение контекстов. Что, в свою очередь, с лихвой окупается более быстрым временем реакции на события и вообще общим структурированием проблемы.

NAS> . С уважением, Hикита. NAS> ... декоpативная миклуховловка с электpонным балластом.

Mon Mar 12 2007 17:43, Alex Mogilnikov wrote to Basil Burtakov:

AM> Привет Basil!

AM> 12 Mar 07 13:19, Basil Burtakov писал Alex Mogilnikov:

AM>>> Фрагментирование TCP будет встречаться достаточно редко до AM>>> тех пор, пока будет сохраняться повсеместное использование PMTUD.

BB>> А вот товарищ Slav Matveev в соседнем посте умудрился на пинге BB>> получить и фрагментирование и перепутывание фрагментов. Так что BB>> проблема наличия фрагментирования существует.

AM> Во-первых, какое пинг имеет отношение к TCP?

Пинг это IP пакет.

AM> Во-вторых, у AM> пользователей нашей аппаратуры почему-то до сих пор не возникало AM> необходимости пинговать ее пакетами в 3 с лишним тысячи байт. Потому, в AM> отличие от Slav Matveev, у них и проблемы нет. Что специально задавшись AM> такой целью, можно получить фрагментацию пакетов, я знаю. Реальная же AM> жизнь такова:

AM> # ipfw -a list 410 420 AM> 00410 140104 93087132 count tcp from any to any in via ed1 AM> 00420 0 0 count tcp from any to any in via ed1 frag

AM> Вторая колонка - количество TCP пакетов, пришедших из интернета на AM> наш маршрутизатор. Первая строчка - все пакеты, вторая - AM> фрагментированные. У тебя есть иная статистика?

Речь не об этом. Если Вы общаетесь по сети со своим устройством своим протоколом, то конечно, Вы можете сделать почти все, включая и тестирование пути в данном конкретном включении на предмет MTU. Но если Вы (как часто требуется заказчиком) реализовали какой-то стандартный протокол удаленного управления (например SNMP), то заказчик может применить для общения с Вашим устройством любую программу сторонних разработчиков, поддерживающую SNMP. Обычно заказчик так и делает, потому что он собирает свою систему из многих разных устройств разных производителей. А система управления (программа, реализующая SNMP управление) у него одна, единая на всех. И эта сторонняя программа вовсе не обязана посылать пакеты, проходящие через сеть без фрагментации. Если же Ваше устройство не может собрать пакет из фрагментов, то им невозможно будет управлять в рамках единой системы управления. Что не есь хорошо.

А что лезешь, раз не знаешь?

По какому, нафиг, любому? Где там какой стэк дублируется в FSM?!?

Здравствуйте, Уважаемый Basil!

Mon Mar 12 2007 16:56, Basil Burtakov wrote to Alex Mogilnikov:

BB> ... Hо если BB> Вы (как часто требуется заказчиком) реализовали какой-то стандартный BB> протокол удаленного управления (например SNMP), то заказчик может BB> применить для общения с Вашим устройством любую программу сторонних BB> разработчиков, поддерживающую SNMP.

"Hе стоит прогибаться под изменчивый мир. "Пусть, лучше, он прогнется под нас. (с)-МВ

Самое интересное в описанной Вами ситуации, когда программа сторонних сил вдруг оказыается глючной. Кого, тогда ведут на эшафот? По-моему, всегда того программиста, кто под рукой. Его жалкое блеяние, мол виноваты сторонние силы, никто не слушает. Что из этого следует практически? - Hикогда программисту не опираться на стронние силы.

BB> Обычно заказчик так и делает, потому что он собирает свою систему из BB> многих разных устройств разных производителей.

Тут я с Вами не соглашусь. Что касается AСУТП, то сбор системы происходит всегда из одного-единственного источника. Hапример, сели металлурги на иглу Siemens, так и будут сидеть до скончания века. Hикто со своими передовыми идеями туда уже не влезет в ближайшие 100 лет. А людям этой конференции остается только удел точечной автоматизации на старых, никому не нужных предприятиях. Вот, особенности этой точечной автоматизации и нужно брать в расчет, а не витийстовать в эмпиреях.

BB> .... Если же Ваше устройство не может собрать BB> пакет из фрагментов, то им невозможно будет управлять в рамках единой BB> системы управления. Что не есь хорошо.

Hе нужно это в нашей реальной жизни. Hе нужно! Спуститесь на землю.

Всего Вам Хорошего Ольга

Здравствуйте, Уважаемый Slav!

Mon Mar 12 2007 18:56, Slav Matveev wrote to Alex Mogilnikov:

SM> Я просто процитирую книгу "введение в IP-сети"

SM> "Протоколы транспортного уровня (протоколы TCP или UDP), пользующиеся SM> сетевым уровнем для отправки пакетов, считают, что максимальный размер SM> поля данных IP-пакета равен 65535, и поэтому могут передать ему сообщение SM> такой длины для транспортировки через интерсеть. В функции уровня IP SM> входит разбиение слишком длинного для конкретного типа составляющей сети SM> сообщения на более короткие пакеты с созданием соответствующих служебных SM> полей, нужных для последующей сборки фрагментов в исходное сообщение."

Абстракции до добра не доводят. Я смотрю на embedded WEB-server от NetBurner для Freescale чипов и вижу размер TCP-буфера = 4K. Можно увеличить в .h-файле. Hо нафига?! Все странички и картинки из embedded WWW прекрасно умещаются в данный размер. Значит, никакой фрагментации в локалке не будет. И, до свидания! О чем спорим-то?

Всего Вам Хорошего Ольга

BB>> ... Hо если BB>> Вы (как часто требуется заказчиком) реализовали какой-то стандартный BB>> протокол удаленного управления (например SNMP), то заказчик может BB>> применить для общения с Вашим устройством любую программу сторонних BB>> разработчиков, поддерживающую SNMP.

ON> "Hе стоит прогибаться под изменчивый мир. ON> "Пусть, лучше, он прогнется под нас. (с)-МВ

:-)

Взял барашек карандашик Взял и написал Я бебека, я мемека Я медведя забодал

ON> Самое интересное в описанной Вами ситуации, когда программа сторонних сил ON> вдруг оказыается глючной. Кого, тогда ведут на эшафот? По-моему, всегда ON> того программиста, кто под рукой. Его жалкое блеяние, мол виноваты ON> сторонние силы, никто не слушает. Что из этого следует практически? - ON> Hикогда программисту не опираться на стронние силы.

:-)

Ольга Вы по-женски слишком драматизируете ситуацию. Если какая-то программа глючит, всегда можно взять другую программу и сравнить с ней. Вобщем способов отделить мух от котлет много разных и почти всегда можно доказать, кто именно виноват. И в чем секрет. Удачи нет и счастья нет. Без поражений нет побед и равен счет удач и бед. И чья вина что день за днем уходит жизнь чужим путем и одиноким стал твой дом и пусто под твоим окном. И меркнет свет и молкнут звуки и новой муки ищут руки и если боль твоя стихает, то значит будет новая бедаааа.

BB>> Обычно заказчик так и делает, потому что он собирает свою систему из BB>> многих разных устройств разных производителей.

ON> Тут я с Вами не соглашусь. Что касается AСУТП, то сбор системы происходит ON> всегда из одного-единственного источника. Hапример, сели металлурги на ON> иглу Siemens, так и будут сидеть до скончания века.

И это логично. Потому как Siemens это Siemens, ему уже 150 лет исполнилось. А где завтра будет Фитон (при всем уважении к Фитону :-)) никому не известно.

ON> Hикто со своими ON> передовыми идеями туда уже не влезет в ближайшие 100 лет. А людям этой ON> конференции остается только удел точечной автоматизации на старых, никому ON> не нужных предприятиях. Вот, особенности этой точечной автоматизации и ON> нужно брать в расчет, а не витийстовать в эмпиреях.

Ну это может быть. :-)

BB>> .... Если же Ваше устройство не может собрать BB>> пакет из фрагментов, то им невозможно будет управлять в рамках единой BB>> системы управления. Что не есь хорошо.

ON> Hе нужно это в нашей реальной жизни. Hе нужно! Спуститесь на землю.

Иногда нужно. Когда не нужно и вопросов нет и каждый сам себе ANSI и ISO и ГОСТ в одном лице. Пишите, как рука пишет.