MMU

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

Wed Mar 07 2007 08:33, Roman Gorbunov wrote to Olga Nonova:

ON>>>> .... Отправлять самому себе, они потом ON>>>> придут, но уже в правильном порядке.

BB>>> будут обрабатывать другие узлы?

RG> Здается мне отфильтруется ваш пакет на первом же свиче и обратно вы его RG> не получите. А роутер тоже может прибить пакет у которого Source & Dest. RG> одинаковые.

Я, признаться, сама не пробовала. Ибо таких проблем с перепутыванием порядка следования не встречала. Hо и пробовать не хочу, т.к. сознательно перепутать пакеты в тестовой последовательности- это по-моему нетривиальнгая задача.

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

Reply to
Olga Nonova
Loading thread data ...
2007-03-06, Olga Nonova snipped-for-privacy@starline.ee пишет:

На самом деле -- это дело того разработчика.

Поскольку фирма, которая купит кривую жэлезку -- как-то наверное выкрутится. А фирма, которая известна тем, что продаёт неюзабельный кривой отстой -- вряд ли.

Reply to
Ilya Anfimov
2007-03-06, Olga Nonova snipped-for-privacy@starline.ee пишет:

И вот как раз в home automation граничные случаи будут проявляться по полной. А часто -- и вообще запредельные. Дикари-с, что взять.

Reply to
Ilya Anfimov

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

Wed Mar 07 2007 12:11, Basil Burtakov wrote to Olga Nonova:

BB>>> Да, обычно самопальные устройства стоят в локалке, где нет даже BB>>> фрагментирования пакетов. Hо это сильно необщий случай.

ON>> Подозреваю, что для ембеддера = это единственно,стоящее внимания дело. ON>> Тут и home-automation (см. web-server на восьминожковом PIC), тут и ON>> различные реализции АСУТП, тут и корпоративные бизнесс-системы....-очень ON>> много чего делается на Ethernet в локалке, без выхода во внешний мир. И ON>> ситуация с передачей пакетов здесь значительно более благоприятная, ON>> нежели прописано в стандартах RFC. Этим можно воспользоваться, чтобы не ON>> излишне не усложнять хардваре.

BB> Hу, в такой постановке вопрос тоже имеет место быть. Это как-бы такой СОМ BB> порт, но по езернету. Когда ничего не теряется, ничего не фрагментируется BB> плюс бонус в виде маршрутизации, зашитой в формат протокола.

Hе совсем СOM. Там еще возникает великолепная возможность обойтись вообще без OS и прочих FrontEnd, а просто обычным в системе браузером. Да и вообще, http нормально ложится на построение распределенных систем управления. По крайней мере, сейчас именно сюда направлены усилия гигантов софвтваре.

BB> В локалке обычно хватает UDP. Да и не в локалке для встроенных систем BB> обычно ограничиваются UDP, бо TCP это достаточно обязывающая задача.

Тут надо играть по правилам, о которых Вы сами-же пишете ниже.

BB> Тем не менее они существуют и востребованы. Часто заказчики требуют, BB> чтобы девайс мониторился каким-то стандартным протоколом, коих несть BB> числа. Вернее, конкуренты предоставляют заказчикам такую возможность, BB> поэтому приходится реализовывать. И, как назло, большинство из этих BB> протоколов базируются на TCP.

Это все от неграмотности заказчиков. Кто они? - Как правило манагеры, ничего не смыслящие в ИТ. Поэтому и получается- раз у всех TCP/IP, значит -вынь да положь, чтобы быть не хуже других. Может, для целей маркетинга это и правильно, но со здравым смыслом очень сильно конфликтует. Причем, я заметила, здравый смысл рано или поздно, но побеждает. Так, может сразу девелеперу основываться на здравом смысле, а не на рыночных перипетиях? Пока то, да се, глядишь, и оказываешься в фокусе востребованности. У меня постоянно так происходит, извините за назойливость.

BB>>> "аппаратный стек TCP/IP". Ставьте такую и будет счастье.

ON>> Спасибо за инфу.

BB> Служу Советскому Союзу :-) Привет Фитону и фитонщикам. :-) Кстати, BB> мужики, поздравляю вас с Международным Женским днем. :-)

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

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

Reply to
Olga Nonova

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

Wed Mar 07 2007 15:39, Ilya Anfimov wrote to Olga Nonova:

IA> И вот как раз в home automation граничные случаи будут проявляться IA> по полной. А часто -- и вообще запредельные. Дикари-с, что взять.

Про "граничные случаи" давайте конкретно. Hапример в контексте Microsoft HomeNet. Чего там, говорите, может не так работать?

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

Reply to
Olga Nonova

ON> Это все от неграмотности заказчиков. Кто они? - Как правило манагеры, ON> ничего не смыслящие в ИТ. Поэтому и получается- раз у всех TCP/IP, значит ON> -вынь да положь, чтобы быть не хуже других. Может, для целей маркетинга ON> это и правильно, но со здравым смыслом очень сильно конфликтует. Причем, ON> я заметила, здравый смысл рано или поздно, но побеждает. Так, может сразу ON> девелеперу основываться на здравом смысле, а не на рыночных перипетиях? ON> Пока то, да се, глядишь, и оказываешься в фокусе востребованности. У меня ON> постоянно так происходит, извините за назойливость.

Если лидеры рынка предлагают возможность управления через сеть, то заявления "да вам это не надо" звучат как-то несерьезно...

Reply to
Basil Burtakov
Reply to
Alexander V. Lushnikov

Thu Mar 08 2007 19:14, Michael Mamaev wrote to Basil Burtakov:

MM> Шнyp жи%, Basil. MM> Втоpник Маpт 06 2007 11:19, Basil Burtakov wrote to Alex Mogilnikov:

BB>> не знаю, как Вы смогли договоpиться с ICANN, чтобы Вам пеpсонально BB>> пpисылали только нефpагментиpованные пакеты :-).

MM> Отлаживались в тепличных yсловиях, очевидно. MM> Пpи пеpеходе на какой-нибyдь GPRS такая pеализация загнется.

Насколько я понимаю, в те времена, когда создавался TCP/IP, фрагментация является средством балансирования нагрузки при сопряжении каналов разной пропускной способности и разного приоритета трафика. Хотя сейчас, с появлением оптики с ее бешенными скоростями, может быть это средство несколько утратило свое значение. Хотя, с другой стороны, теперь и объемы гоняют поболее, чем тогда. Одно видео чего стоит.

BB>> Hо в pеальной жизни на это pассчитывать не пpиходится.

MM> Майкл

Reply to
Basil Burtakov

MM>>> Пpи пеpеходе на какой-нибyдь GPRS такая pеализация загнется.

BB>> Hасколько я понимаю, в те времена, когда создавался TCP/IP, BB>> фрагментация является средством балансирования нагрузки при сопряжении BB>> каналов разной пропускной способности и разного приоритета трафика. BB>> Хотя сейчас, с появлением оптики с ее бешенными скоростями, может быть BB>> это средство несколько утратило свое значение. Хотя, с другой стороны, BB>> теперь и объемы гоняют поболее, чем тогда. Одно видео чего стоит.

SM> извините что вмешиваюсь, но по-моему вы во-1 путаете SM> размер ip пакета и размер пакета на конкретной среде передачи данных, SM> а во-2 никто и никогда даже на бешеных скоростях оптики SM> не гарантирует что второй пакет пойдет тем же маршрутом, что SM> и первый. все-таки это чаще сети с коммутацией пакетов, SM> чем каналов.

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

Соответственно и та часть стандарта TCP/IP, которая говорит, что фрагменты могут быть задержаны-перемешаны тоже сильно завист от текущих сетевых технологий. Если все юзеры подключены к магистрали без колец топологии, то "другим маршрутам" просто неоткуда взяться.

SM> Slav.

Reply to
Basil Burtakov
Reply to
Alex Mogilnikov
Reply to
Alex Mogilnikov

SM>>> маршрутом, что и первый. все-таки это чаще сети с коммутацией SM>>> пакетов, чем каналов.

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

SM> на уровне tcp/udp резонно полагают что размер пакета SM> может быть 64К. поэтому уровню ip придется его нашинковать SM> не при переходе из эзернета в ппп, а намного раньше: уже SM> на отправителе.

BB>> Хотя опять же вроде сейчас тенденция перехода на сети с маленьким MTU BB>> порядка десятков-сотен байт типа технологии ATM.

SM> технологии атм - сто лет в обед. а вот jumbo frames на гигабите SM> наоборот увеличивают размер кадра. причем их применение SM> заметно повышает пропускную способность и снижает cpu load.

Гигабит это технология локалки, тут не надо балансировать загрузку. А вот при доступе к магистрали мультиплексор получает данные от разных источников. Один источник быстрый, другой медленный, их производительности в рантайме меняются, источников очень много. А мультиплексор должен в том числе обеспечить максимальную загрузку мощного канала. Если в мощном канале MTU маленький, то это сделать вроде-бы проще.

BB>> Соответственно и та часть стандарта TCP/IP, которая говорит, что BB>> фрагменты могут быть задержаны-перемешаны тоже сильно завист от BB>> текущих сетевых технологий. Если все юзеры подключены к магистрали без BB>> колец топологии, то "другим маршрутам" просто неоткуда взяться.

SM> если говорить о сферическом коне... то конечно, взяться неоткуда. SM> можно даже предположить что вообще никаких маршрутов. SM> но в реальности получается вот как-то так:

SM> 9 so-12-0.hsa3.SanJose1.Level3.net (4.68.125.146) 226.762 ms 230.270 SM> ms so-14-0.hsa3.SanJose1.Level3.net (4.68.114.154) 229.045 ms

SM> третий пакет пошел своим путем.

Это пинги что-ли? Нет, вы сделайте так, чтобы пакет побился на фрагменты, а третий фрагмент пришел не тем путем, что первые два. А еще лучше, чтобы третий пришел раньше, чем второй.

SM> Slav.

Reply to
Basil Burtakov

:-). Ещё и очень развесистыми обработчиками. Начиная с некоторого уровня сложности количество переходит в качество и код становится несопровождабельным. Увы. Других, кроме этого ограничения, причин для использования ОС, потоков, шедулера да и языка С вместо супер эффективного асма :-)) действительно нет.

Скажем так - раньше было нехарактерно, теперь это уже столь однозначно. Если даже появится клон эхотажного линукса или вэиксворкса для восьмой меги, то я, пожалуй, воздержусь от его внедрения :-))). Но для полноразмерного АРМа, поставленного не просто так, а под соответствующую задачу ...

Reply to
Alexander Derazhne

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.