MMU

Reply to
Michael Mamaev
Loading thread data ...
Reply to
Alex Mogilnikov

Thu Mar 01 2007 00:31, Alex Mogilnikov wrote to Michael Mamaev:

AM> Привет Michael!

AM> 28 Feb 07 19:40, Michael Mamaev писал Alex Mogilnikov:

MM>> А нельзя ли yвидеть более-менее вменяемyю эхотажнyю pеализацию TCP/IP MM>> в исходниках, да еще и без использования кyчи?

AM> Если вопрос конкретно ко мне, то увидеть нельзя. Предлагаю поверить AM> мне на слово, что у меня такая есть и используется.

Если не секрет, как реализована сборка пакетов на преме из кусков разной длины? :-)

Еще вопрос - используется ли шедулер? Или все крутится в одной задаче - главном цикле?

Reply to
Basil Burtakov

Thu Mar 01 2007 00:31, Alex Mogilnikov wrote to Michael Mamaev:

AM> Привет Michael!

AM> 28 Feb 07 19:40, Michael Mamaev писал Alex Mogilnikov:

MM>> А нельзя ли yвидеть более-менее вменяемyю эхотажнyю pеализацию TCP/IP MM>> в исходниках, да еще и без использования кyчи?

AM> Если вопрос конкретно ко мне, то увидеть нельзя. Предлагаю поверить AM> мне на слово, что у меня такая есть и используется.

Если не секрет, как реализована сборка пакетов на приеме из кусков разной длины? :-)

Еще вопрос - используется ли шедулер? Или все крутится в одной задаче - главном цикле? А то мне тут в одном месте на полном серьезе втирали, что TCP/IP отлично реализуется в однозадачном мониторе. :-)

Reply to
Basil Burtakov

BB>> Если не секрет, как реализована сборка пакетов на преме из кусков BB>> разной длины? :-)

AM> Hикак. Пока еще ни в одном из применений такой функциональности не AM> потребовалось. Все пакеты укладываются в 1500 байт. У меня даже на AM> персоналке долгое время (годы) было прописано deny ip from any to any AM> frag...

Да, так часто делают. Особенно для применений, которые общаются только внутри одной езернетовской локалки. Например для кассовых аппаратов, которые никто не мониторит извне. Однако, как Вы сами понимаете, такое решение никак нельзя назвать "полноценной реализацией TCP/IP". Скорее это "средство перепихнуться по UDP в пределах локалки". Или даже "средство для обмена езернетовскими пакетами в стандарте UDP для того, чтобы через локальные роутеры эти пакеты все-таки проходили". Однако если такой устройство поставить в нормальную сеть и попробовать пообщаться с ним издалека, то можно получить отлуп. Например, связное сетевое оборудование почти всегда имеет технологический канал для мониторинга и настроек. Если производитель, как часто бывает, находится в Тайбее :-), а аппаратура стоит на Камчатке, то техсаппорт теоретически можно осуществлять удаленно. Но если реализация TCP/IP не поддерживает сборку фрагментированных пакетов, а на пути от Тайбея до Камчатки проложена линия с максимальным размером пакета меньше, чем в езернете, то несмотря на исправность всех технических средств связи получить не удасться.

BB>> Еще вопрос - используется ли шедулер? Или все крутится в одной задаче BB>> - главном цикле?

AM> Шедулер используется, для сетевизмов (разбор принятого) создается AM> отдельная задача. Она в-основном очередь приема разбирает.

Reply to
Basil Burtakov

BB>> А то мне тут в одном месте на полном серьезе втирали, BB>> что TCP/IP отлично реализуется в однозадачном мониторе. :-)

AM> Лишь бы своевременно разбиралась очередь принимаемых пакетов. AM> Понятно, что отдельная задача, которую пробуждает шедулер при появлении AM> чего-то в очереди, удобнее. Hо не вижу принципиальных препятствий делать AM> это же путем периодической проверки очереди в каком-то цикле. Отличным я AM> бы это не назвал, :) но работать, по идее, должно...

Работать будет при многих ограничениях. Например без шедулера невозможно определить перерыв в связи (невозможно как положено в TCP/IP на каждый пакет запускать свой таймер и сбрасывать пакет, если не все его части пришли до истечения таймаута). То есть пакет должен быть принят сразу и целиком. То есть это опять UDP, а а вовсе не TCP/IP. Ну и общий недостаток главного цикла - долгая низкоприоритетная задача не отпускает управление, хотя в это время надо обслужить что-то более высокоприоритетное.

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

Thu Mar 01 2007 16:49, Sergei Podstrigailo wrote to Basil Burtakov:

SP> Hello Basil!

SP> 01 Mar 35 10:52, Basil Burtakov wrote to Alex Mogilnikov:

BB>> Еще вопрос - используется ли шедулер? Или все крутится в одной задаче BB>> - главном цикле? А то мне тут в одном месте на полном серьезе втирали, BB>> что TCP/IP отлично реализуется в однозадачном мониторе. :-)

SP> MS-DOS пойдет как пример однозадачного монитора? :-)

SP> Реализаций TCP/IP под него (было) в ассортименте...

Реализация реализации рознь. Если реализация более-менее полноценная, то там свой шедулер, который принимает управление и мимо ДОСа работает, часто даже в защищенном режиме. У микрософта, кстати, есть такая система, называется Msclient.

SP> Sergei

Reply to
Basil Burtakov
Reply to
Sergei Podstrigailo

AM>>> У меня даже на персоналке долгое время (годы) было AM>>> прописано deny ip from any to any frag...

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

AM> Да это было не специально так задумано, просто когда-то в файрволе AM> нашли багу, в результате которой хитрым образом сделанный целый пакет AM> ошибочно подпадал под правило для фрагмента. Мне сразу обновиться было AM> некогда, и я просто вместо pass поставил deny. А после обновления вернуть AM> обратно забыл. :) Так и стояло несколько лет...

BB>> Однако, как Вы сами понимаете, такое BB>> решение никак нельзя назвать "полноценной реализацией TCP/IP". Скорее BB>> это "средство перепихнуться по UDP в пределах локалки".

AM> Hе согласен. Во-первых, не обязательно в локалке. Аппаратура реально AM> работает в довольно протяженных и разветвленных сетях. Во-вторых, из всех AM> протоколов, с которыми мне приходилось иметь дело, многокилобайтные UDP AM> пакеты используются только в NFS. По крайней мере, для эхотага, разборка AM> больших пакетов на фрагменты - скорее экзотика чем правило. Для TCP же, AM> насколько я знаю, даже если не используется PMTUD, при котором пакеты AM> вообще идут с флагом DF, есть присланный с другой стороны MSS...

AM> Все, что до сих пор было нужно как мне, так и моим коллегам (RIP, AM> NTP, SNMP, telnet, HTTP...), без проблем работает и с пакетами до 1500 AM> байт. Так что в этом смысле неполноценной я эту реализацию не считаю. В AM> ней есть другие моменты, дающие гораздо больше оснований считать ее не AM> совсем полноценной, но к использованию кучи они никакого отношения не AM> имеют.

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

AM> Верно. Только к использованию кучи это не имеет отношения. Пакет AM> размером до 1500 байт может быть собран из фрагментов в одном AM> фиксированном буфере.

А если часть второго пакета для этого же соединения пришла раньше, чем собрался первый пакет? По спецификации даже UDP (а тем более TCP/IP) такое вполне может быть. А у Вас тлько один статический буфер для сборки пакетов и нет возможности запросить новый буфер и начать сборку второго пакета, не собрав первый.

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

AM>>> Верно. Только к использованию кучи это не имеет отношения. AM>>> Пакет размером до 1500 байт может быть собран из фрагментов в AM>>> одном фиксированном буфере.

BB>> А если часть второго пакета для этого же соединения пришла раньше, чем BB>> собрался первый пакет? По спецификации даже UDP (а тем более TCP/IP) BB>> такое вполне может быть.

AM> А какое имеет значение порядок прихода фрагментов?

BB>> А у Вас тлько один статический буфер для

AM> Да вольно уже! Что ты меня который уже раз на Вы называешь?

BB>> сборки пакетов и нет возможности запросить новый буфер и начать сборку BB>> второго пакета, не собрав первый.

AM> ? Зачем такой экстремизм - _только_ один буфер? :))) Сколько AM> требуется - столько и надо брать. С разумными ограничениями, конечно. Я AM> имел в виду, что буфера фиксированного размера будет достаточно для AM> сборки одного полного пакета, и необходимости выделять память из кучи AM> нет.

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

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

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Программисты знают, что на каждую улицу Пушкина должна быть улица AM> Попкина.

Reply to
Basil Burtakov

BB>> Это и есть нехорошо, ибо выделенная статически память навсегда BB>> заземлена для задачи связи. Связь нужна далеко не постоянно.

AM> Это кому как. У меня везде, где используются сетевизмы, они нужны AM> постоянно - 24 часа в сутки и 7 дней в неделю.

Что там у Вас, видеопоток обрабатывается что-ли? Раз в секунду-минуту-час приходит пакет, а все остальное время память может (и должна) использоваться другими задачами.

BB>> А куча позволяет гибко перераспределять BB>> ресурс памяти между задачами в рантайме.

AM> С этим вроде бы никто не спорил. Спорили с утверждением, что без AM> использования кучи нельзя сделать приемлемо функциональный TCP/IP стек.

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

Reply to
Basil Burtakov
Reply to
Alex Mogilnikov

Basil Burtakov пишет:

Осталось только объяснить окружающему миру, что пакеты должны приходить "раз в секунду-минуту-час", по расписанию, утверждённому нашим устройством.

Reply to
Ivan Maximov

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.