MMU

BB> òÁÂÏÔÁÔØ ÂyÄÅÔ ÐpÉ ÍÎÏÇÉÈ ÏÇpÁÎÉÞÅÎÉÑÈ. HÁÐpÉÍÅp ÂÅÚ ÛÅÄyÌÅpÁ BB> ÎÅ×ÏÚÍÏÖÎÏ ÏÐpÅÄÅÌÉÔØ ÐÅpÅpÙ× × Ó×ÑÚÉ (ÎÅ×ÏÚÍÏÖÎÏ ËÁË ÐÏÌÏÖÅÎÏ × BB> TCP/IP ÎÁ ËÁÖÄÙÊ ÐÁËÅÔ ÚÁÐyÓËÁÔØ Ó×ÏÊ ÔÁÊÍÅp É ÓÂpÁÓÙ×ÁÔØ ÐÁËÅÔ, ÅÓÌÉ óÉÌØÎÏ. ëÁË Ó×ÑÚÁÎÙ ÎÁÌÉÞÉÅ ÛÅÄyÌÅpÁ É ÍÎÏÇÏÐÏÔÏÞÎÏÓÔØ Ó ×ÏÚÍÏÖÎÏÓÔØÀ ÚÁ×ÅÓÔÉ ÎÅÓËÏÌØËÏ ÔÁÊÍÅpÏ×?

BB> Hy É ÏÂÝÉÊ ÎÅÄÏÓÔÁÔÏË ÇÌÁ×ÎÏÇÏ ÃÉËÌÁ - ÄÏÌÇÁÑ ÎÉÚËÏÐpÉÏpÉÔÅÔÎÁÑ BB> ÚÁÄÁÞÁ ÎÅ ÏÔÐyÓËÁÅÔ yÐpÁ×ÌÅÎÉÅ, ÈÏÔÑ × ÜÔÏ ×pÅÍÑ ÎÁÄÏ ÏÂÓÌyÖÉÔØ BB> ÞÔÏ-ÔÏ ÂÏÌÅÅ ×ÙÓÏËÏÐpÉÏpÉÔÅÔÎÏÅ. ôÁËÉÈ ÚÁÄÁÞ × ÔÁËÏÊ ÓÉÓÔÅÍÅ ÂÙÔØ ÎÅ ÄÏÌÖÎÏ, ÔÏÌØËÏ É ×ÓÅÇÏ. ìÅÞÉÔÓÑ pÁÚÂÉÅÎÉÅÍ ÉÈ ÎÁ ÞÁÓÔÉ (Ó ÎÅËÏÔÏpÙÍ yÓÌÏÖÎÅÎÉÅÍ ÁÌÇÏpÉÔÍÁ, y×Ù).

02 Mar 07 20:22, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

BB> òÁÚ × BB> ÓÅËÕÎÄÕ-ÍÉÎÕÔÕ-ÞÁÓ ÐÒÉÈÏÄÉÔ ÐÁËÅÔ, Á ×ÓÅ ÏÓÔÁÌØÎÏÅ ×ÒÅÍÑ ÐÁÍÑÔØ ÍÏÖÅÔ BB> (É ÄÏÌÖÎÁ) ÉÓÐÏÌØÚÏ×ÁÔØÓÑ ÄÒÕÇÉÍÉ ÚÁÄÁÞÁÍÉ.

AM>> óÐÏÒÉÌÉ Ó ÕÔ×ÅÒÖÄÅÎÉÅÍ, ÞÔÏ AM>> ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ËÕÞÉ ÎÅÌØÚÑ ÓÄÅÌÁÔØ ÐÒÉÅÍÌÅÍÏ ÆÕÎËÃÉÏÎÁÌØÎÙÊ AM>> TCP/IP ÓÔÅË.

BB> íÏÖÎÏ, ÎÏ ÔÏÇÄÁ ÎÁÄÏ ÏÔÄÁÔØ ×ÓÀ ÐÁÍÑÔØ ÎÁ ÓÅÔÅ×ÕÀ ÚÁÄÁÞÕ,

(ÎÅ ÇÏ×ÏÒÑ ÕÖÅ Ï ÔÏÍ, ÞÔÏ ÐÒÉ ÐÒÏÅËÔÉÒÏ×ÁÎÉÉ ÕÓÔÒÏÊÓÔ×Á × ÎÅÇÏ ÏÂÙÞÎÏ ÐÁÍÑÔØ ÚÁËÌÁÄÙ×ÁÀÔ ÉÓÈÏÄÑ ÉÚ ÐÏÔÒÅÂÎÏÓÔÅÊ ÚÁÄÁÞ, Á ÎÅ ÁÂÙ ÓËÏÌØËÏ...)

03 Mar 07 19:49, Michael Mamaev ÐÉÓÁÌ Alex Mogilnikov:

AM>> åÓÌÉ ×ÏÐpÏÓ ËÏÎËpÅÔÎÏ ËÏ ÍÎÅ, ÔÏ y×ÉÄÅÔØ ÎÅÌØÚÑ. ðpÅÄÌÁÇÁÀ AM>> ÐÏ×ÅpÉÔØ ÍÎÅ ÎÁ ÓÌÏ×Ï, ÞÔÏ y ÍÅÎÑ ÔÁËÁÑ ÅÓÔØ É ÉÓÐÏÌØÚyÅÔÓÑ.

MM> åÓÔØ ÐpÉÞÉÎÙ ÎÅ ×ÅpÉÔØ ÎÁ ÓÌÏ×Ï...

MM> ïÎÏ, ÔÁË ÐÏÎÉÍÁÀ, ÎÅ ÐpÏÄÁÅÔÓÑ (ÎÉËÏÍy ÎÅ ÎyÖÎÏ?)

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

Действительно, увы. Есть несколько потоков, которые по традиции, в РВ системах называются задачами :-). Одна - "высокоприоритетная", перемалывает поток данных. Другая - "низкоприоритетная", устанавливает режимы работы для первой по заказу удалённого вышестоящего процессора. Просто присвоить им разные приоритеты нельзя (подерутся за разделяемые переменные), обложить локами тоже нельзя - уйдёт слишком много времени. Вот и приходится держать их на одном приоритете, превращая заложеную в ОС вытесняющую многозадачность в кооперативную.

Sat Mar 03 2007 00:16, Ivan Maximov wrote to Basil Burtakov:

IM> From: Ivan Maximov snipped-for-privacy@mtu-net.ru

IM> Basil Burtakov пишет:

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

Ну, сетевая задача она не такая уж ресурсоемкая, если конечно устройство не есть специализированный роутер, который только и сделан для того, чтобы молотить поток. Типично, устройство имеет основную задачу, а сеть используется для того, чтобы дистанционно настроить параметры/снять диагностику. Параметры настраивают не постоянно, а эпизодически.

Можно оценить загрузку контроллера со стороны сетевой задачи. Если сеть это езернет 100 мегабит, и приходят пакеты в 1Кбайт размером, то типовой современный риск контроллер с тактовой 50МГц за время прихода пакета (даже если пакеты идут подряд) успеет выполнить 5000 команд. Согласитесь, это достаточно много.

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

AM> Хм. А откуда у тебя приходящий пакет знает, что "вот сейчас можно AM> придти" или "а вот сейчас лучше не приходить, сейчас память в том AM> устройстве используется другими задачами, надо подождать пару минут тут в AM> проводах пока память не освободится."? :))

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

BB>> Можно, но тогда надо отдать всю память на сетевую задачу,

AM> И это неверно. Hе надо отдавать всю память. Hадо отдавать столько, AM> сколько требуется.

Нет, систему надо строить так, чтобы она само могла в рантайме перераспределять ресурсы (в том числе ресурсы памяти и быстродействия). При этом может быть, что низкоприоритетные некритичные задачи на какое-то время будут отказывать в обслуживании. Такая постановка вопроса позволяет проектировать оптимальную по ресурсам (то есть оптимальную по стоимости) систему.

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

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

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

BB>>>> Можно, но тогда надо отдать всю память на сетевую задачу,

AM>>> И это неверно. Hе надо отдавать всю память. Hадо отдавать AM>>> столько, сколько требуется.

BB>> Hет, систему надо строить так, чтобы она само могла в рантайме BB>> перераспределять ресурсы (в том числе ресурсы памяти и быстродействия).

AM> Если надо, что мешает это делать? Hе вижу, как их этого утверждения AM> следует, что под сетевую задачу надо выделить _всю_ память.

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

Таким образом получаем:

1. Можно отдать статически всю память (или значительную часть памяти) системы сетевой задаче. Тогда, в пределах выделенных ресурсов, стек TCP/IP будет реализован с максимальной полнотой.

1. Можно сделать кучу и отдавать память стеку по мере поступления от него запросов на память. Этот подход позволяет делать еще какую-то полезную работу, кроме связи. При этом задача связи получает в каждый данный момент столько ресурсов, сколько система может ей выделить. Соответственно, качество обслуживания канала в точности соответствует суммарной производительности системы с учетом приоритетов, назначенных задачам.

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Крыскас. Потому что крыса вам доверяет.

05 Mar 07 11:52, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

AM>>>> óÐÏÒÉÌÉ Ó ÕÔ×ÅÒÖÄÅÎÉÅÍ, ÞÔÏ AM>>>> ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ËÕÞÉ ÎÅÌØÚÑ ÓÄÅÌÁÔØ ÐÒÉÅÍÌÅÍÏ ÆÕÎËÃÉÏÎÁÌØÎÙÊ AM>>>> TCP/IP ÓÔÅË.

BB>>> íÏÖÎÏ, ÎÏ ÔÏÇÄÁ ÎÁÄÏ ÏÔÄÁÔØ ×ÓÀ ÐÁÍÑÔØ ÎÁ ÓÅÔÅ×ÕÀ ÚÁÄÁÞÕ,

AM>> é ÜÔÏ ÎÅ×ÅÒÎÏ. HÅ ÎÁÄÏ ÏÔÄÁ×ÁÔØ ×ÓÀ ÐÁÍÑÔØ. HÁÄÏ ÏÔÄÁ×ÁÔØ AM>> ÓÔÏÌØËÏ, ÓËÏÌØËÏ ÔÒÅÂÕÅÔÓÑ.

BB> HÅÔ, ÓÉÓÔÅÍÕ ÎÁÄÏ ÓÔÒÏÉÔØ ÔÁË, ÞÔÏÂÙ ÏÎÁ ÓÁÍÏ ÍÏÇÌÁ × ÒÁÎÔÁÊÍÅ BB> ÐÅÒÅÒÁÓÐÒÅÄÅÌÑÔØ ÒÅÓÕÒÓÙ (× ÔÏÍ ÞÉÓÌÅ ÒÅÓÕÒÓÙ ÐÁÍÑÔÉ É BB> ÂÙÓÔÒÏÄÅÊÓÔ×ÉÑ).

BB> Таким образом получаем:

BB> 1. Можно отдать статически всю память (или значительную часть памяти) BB> системы сетевой задаче. Тогда, в пределах выделенных ресурсов, стек BB> TCP/IP будет реализован с максимальной полнотой.

Кстати, даже в этом случае куча все равно нужна. Так как все равно пакеты приходят побитые на куски и в разные моменты времени. А в статическом буфере на 1.5 килобайта их собирать тоже плохо. Так как есть такой вариант, что от пакета пришел только один кусок, а остальное потерялось. Но под этот кусок отведется 1.5 килобайта и эти 1.5 килобайта будут недоступны для других пакетов, пока не истечет таймаут пакета (то есть десятки минут). Если связь плохая, то таких пакетов может быть много и работа подсистемы связи может быть заблокирована, несмотря на то, что по факту свободной памяти предостаточно.

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

05 Mar 07 17:49, Basil Burtakov ÐÉÓÁÌ Basil Burtakov:

BB> ÅÓÔØ ÔÁËÏÊ ×ÁÒÉÁÎÔ, ÞÔÏ ÏÔ ÐÁËÅÔÁ ÐÒÉÛÅÌ ÔÏÌØËÏ ÏÄÉÎ ËÕÓÏË, Á BB> ÏÓÔÁÌØÎÏÅ ÐÏÔÅÒÑÌÏÓØ. HÏ ÐÏÄ ÜÔÏÔ ËÕÓÏË ÏÔ×ÅÄÅÔÓÑ 1.5 ËÉÌÏÂÁÊÔÁ É ÜÔÉ BB> 1.5 ËÉÌÏÂÁÊÔÁ ÂÕÄÕÔ ÎÅÄÏÓÔÕÐÎÙ ÄÌÑ ÄÒÕÇÉÈ ÐÁËÅÔÏ×, ÐÏËÁ ÎÅ ÉÓÔÅÞÅÔ BB> ÔÁÊÍÁÕÔ ÐÁËÅÔÁ (ÔÏ ÅÓÔØ ÄÅÓÑÔËÉ ÍÉÎÕÔ). åÓÌÉ Ó×ÑÚØ ÐÌÏÈÁÑ, ÔÏ ÔÁËÉÈ BB> ÐÁËÅÔÏ× ÍÏÖÅÔ ÂÙÔØ ÍÎÏÇÏ É ÒÁÂÏÔÁ ÐÏÄÓÉÓÔÅÍÙ Ó×ÑÚÉ ÍÏÖÅÔ BB> ÂÙÔØ ÚÁÂÌÏËÉÒÏ×ÁÎÁ, ÎÅÓÍÏÔÒÑ ÎÁ ÔÏ, ÞÔÏ ÐÏ ÆÁËÔÕ Ó×ÏÂÏÄÎÏÊ ÐÁÍÑÔÉ BB> ÐÒÅÄÏÓÔÁÔÏÞÎÏ.

BB> åÓÌÉ ÖÅ ÐÁÍÑÔØ ×ÙÄÅÌÑÅÔÓÑ ÐÏ ÆÁËÔÉÞÅÓËÏÍÕ ÒÁÚÍÅÒÕ ÐÁËÅÔÁ (ËÕÓËÁ BB> ÐÁËÅÔÁ), ÔÏ ÔÁËÏÇÏ ÎÅ ÐÒÏÉÓÈÏÄÉÔ.

05 Mar 07 17:49, Basil Burtakov ÐÉÓÁÌ Basil Burtakov:

BB> ÅÓÔØ ÔÁËÏÊ ×ÁÒÉÁÎÔ, ÞÔÏ ÏÔ ÐÁËÅÔÁ ÐÒÉÛÅÌ ÔÏÌØËÏ ÏÄÉÎ ËÕÓÏË, Á BB> ÏÓÔÁÌØÎÏÅ ÐÏÔÅÒÑÌÏÓØ. HÏ ÐÏÄ ÜÔÏÔ ËÕÓÏË ÏÔ×ÅÄÅÔÓÑ 1.5 ËÉÌÏÂÁÊÔÁ É ÜÔÉ BB> 1.5 ËÉÌÏÂÁÊÔÁ ÂÕÄÕÔ ÎÅÄÏÓÔÕÐÎÙ ÄÌÑ ÄÒÕÇÉÈ ÐÁËÅÔÏ×, ÐÏËÁ ÎÅ ÉÓÔÅÞÅÔ BB> ÔÁÊÍÁÕÔ ÐÁËÅÔÁ (ÔÏ ÅÓÔØ ÄÅÓÑÔËÉ ÍÉÎÕÔ).

BB> åÓÌÉ Ó×ÑÚØ ÐÌÏÈÁÑ, ÔÏ ÔÁËÉÈ BB> ÐÁËÅÔÏ× ÍÏÖÅÔ ÂÙÔØ ÍÎÏÇÏ É ÒÁÂÏÔÁ ÐÏÄÓÉÓÔÅÍÙ Ó×ÑÚÉ ÍÏÖÅÔ BB> ÂÙÔØ ÚÁÂÌÏËÉÒÏ×ÁÎÁ, ÎÅÓÍÏÔÒÑ ÎÁ ÔÏ, ÞÔÏ ÐÏ ÆÁËÔÕ Ó×ÏÂÏÄÎÏÊ ÐÁÍÑÔÉ BB> ÐÒÅÄÏÓÔÁÔÏÞÎÏ.

BB> åÓÌÉ ÖÅ ÐÁÍÑÔØ ×ÙÄÅÌÑÅÔÓÑ ÐÏ ÆÁËÔÉÞÅÓËÏÍÕ ÒÁÚÍÅÒÕ ÐÁËÅÔÁ (ËÕÓËÁ BB> ÐÁËÅÔÁ), ÔÏ ÔÁËÏÇÏ ÎÅ ÐÒÏÉÓÈÏÄÉÔ.

HÅ ÔÁÍ, ÎÅ ÔÁÍ ÔÙ ÜËÏÎÏÍÉÀ ÉÝÅÛØ. HÁËÌÁÄÙ×ÁÎÉÅÍ _ÒÁÚÕÍÎÙÈ_ ÏÇÒÁÎÉÞÅÎÉÊ ÎÁ ÕÓÌÏ×ÉÑ ÚÁÄÁÞÉ ÄÏÂØÅÛØÓÑ ÇÏÒÁÚÄÏ ÂÏÌØÛÅÇÏ.

BB>> есть такой вариант, что от пакета пришел только один кусок, а BB>> остальное потерялось. Hо под этот кусок отведется 1.5 килобайта и эти BB>> 1.5 килобайта будут недоступны для других пакетов, пока не истечет BB>> таймаут пакета (то есть десятки минут).

AM> Хм. Десятки минут? Таймаут пакета? Довольно странно...

В соответствии со спецификацией TCP/IP.

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

BB>> Если же память выделяется по фактическому размеру пакета (куска BB>> пакета), то такого не происходит.

AM> Что, никогда? Мне кажется, это зависит от объема памяти, скорости AM> прихода пакетов, TTL и т.п. то есть откучи самых разных факторов.

Естественно зависит. Речи идет о том, чтобы при данных ресурсах системы обеспечить максимальное возможное обслуживание.

AM> Посчитай-ка, сколько потребуется ОЗУ для хранения фрагментов по 100 байт AM> каждый, приходящих со скоростью (всего) 1000 пакетов в секунду и хранимых AM> по 250 секунд каждый (про десятки минут даже не заикаюсь).

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

AM> Hе там, не там ты экономию ищешь. Hакладыванием _разумных_ AM> ограничений на условия задачи добьешься гораздо большего.

"Разумных" ограничений не бывает. Бывает:

1. соответствие стандарту
2. несоответствие стандарту как следствие сознательного ограничения цены системы. Но даже и в этом случае из тех аппаратных ресурсов, которые все-таки выделены под решение задачи [задачи связи в обсуждаемом случае], можно и нужно выжимать максимум возможного. Я не знаю, как Вы смогли договориться с ICANN, чтобы Вам персонально присылали только нефрагментированные пакеты :-). Но в реальной жизни на это рассчитывать не приходится.

AM> Всего наилучшего, [Team PCAD 2000] AM> Алексей М. AM> ... Северо-Кавказская межрегиональная ассоциация анонимных соискателей.

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

Tue Mar 06 2007 11:19, Basil Burtakov wrote to Alex Mogilnikov:

AM>> Посчитай-ка, сколько потребуется ОЗУ для хранения фрагментов по 100 байт AM>> каждый, приходящих со скоростью (всего) 1000 пакетов в секунду и AM>> хранимых по 250 секунд каждый (про десятки минут даже не заикаюсь).

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

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

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

AM>>> Посчитай-ка, сколько потребуется ОЗУ для хранения фрагментов по 100 AM>>> байт каждый, приходящих со скоростью (всего) 1000 пакетов в секунду и AM>>> хранимых по 250 секунд каждый (про десятки минут даже не заикаюсь).

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

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

Честно говоря такого коварного решения проблемы фрагментации как отправлять самому себе пакеты с надеждой, что они задержаться в сети я даже в самых смелых своих фантазиях не мог представить. :-) Не думаю, что это хороший выход. Прежде всего потому, что сеть может не понять пакеты со своим же обратным адресом. Как это будут обрабатывать другие узлы? И не прибьют ли они такие пакеты как ошибочные. А если не прибьют, то не отфутболит ли ближайший роутер такой пакет обратно и задержка будет минимальной. Опять же время на передачу тратится, а передатчик может быть нужен для дела. Ну и кроме того это просто некрасиво - дудеть своей информацией засоряя каналы. А если задерженный фрагмент не придет никогда? Так и будете до исчерпания таймаута гонять остальные фрагменты пакета по интернету?

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

06 Mar 07 11:19, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

BB> "òÁÚÕÍÎÙÈ" ÏÇÒÁÎÉÞÅÎÉÊ ÎÅ ÂÙ×ÁÅÔ.

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

Tue Mar 06 2007 14:36, Basil Burtakov wrote to Olga Nonova:

ON>> .... Я вижу проблему здесь только в перепутанной ON>> последовательности поступления пакетов. Hо, опять же, для сервера ON>> выходом может быть просто отправка пакетов, пришедших вне очереди, ON>> обратно в сеть. Отправлять самому себе, они потом придут, но уже в ON>> правильном порядке.

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

Это их дело.

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

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

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

ON>>> .... Я вижу проблему здесь только в перепутанной ON>>> последовательности поступления пакетов. Hо, опять же, для сервера ON>>> выходом может быть просто отправка пакетов, пришедших вне очереди, ON>>> обратно в сеть. Отправлять самому себе, они потом придут, но уже в ON>>> правильном порядке.

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

ON> Это их дело.

Гм... :-)

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

ON> А нефига было перепутывать порядок следования пакетов. Перепутал- ON> получай.

Так это же в спецификации записано. Пакеты в общем случае могут быть побиты на фрагменты и фрагменты перепутаны и продублированы.

ON> Hу, а кроме шуток, в интранет, где собственно и кучкуются обычно ON> ембеддеры, таких ужасностей, как перепутывание порядка следования ON> пакетов, на практике не наблюдается.

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

ON> А управлять чем-то на другом конце ON> земного шара- это экзотика

Роутер Циско это экзотика? Мониторится и настраивается с любого конца Земного шара.

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

В принципе есть (были?) микросхемы, которые обеспечивали четыре одновременных соединений TCP/IP. Сам я не применял, только слышал. Производитель чуть ли не Casio. Надо искать в гугле на слова "аппаратный стек TCP/IP". Ставьте такую и будет счастье.

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

Tue Mar 06 2007 17:01, Basil Burtakov wrote to Olga Nonova:

ON>> Hу, а кроме шуток, в интранет, где собственно и кучкуются обычно ON>> ембеддеры, таких ужасностей, как перепутывание порядка следования ON>> пакетов, на практике не наблюдается.

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

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

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

Я бы сперва занялась обоснованием TCP/IP во встроенных системах. Hафига это вообще нужно в локалке? Hе достаточно ли UDP? Тут сперва неплохо все-таки определиться с потребностями- где нужна куча, а где -нет.

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

А если это все-таки работает без проблем, то какая разница? "Вам шашечки, или ехать? (с)-анекдот.

ON>> А управлять чем-то на другом конце ON>> земного шара- это экзотика BB> Роутер Циско это экзотика? Мониторится и настраивается с любого конца BB> Земного шара.

Я не в курсе столь длинных дистанций.

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

BB> В принципе есть (были?) микросхемы, которые обеспечивали четыре BB> одновременных соединений TCP/IP. Сам я не применял, только слышал. BB> Производитель чуть ли не Casio. Hадо искать в гугле на слова "аппаратный BB> стек TCP/IP". Ставьте такую и будет счастье.

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

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

ON>>> Hу, а кроме шуток, в интранет, где собственно и кучкуются обычно ON>>> ембеддеры, таких ужасностей, как перепутывание порядка следования ON>>> пакетов, на практике не наблюдается.

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

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

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

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

ON> Я бы сперва занялась обоснованием TCP/IP во встроенных системах. Hафига ON> это вообще нужно в локалке? Hе достаточно ли UDP? Тут сперва неплохо ON> все-таки определиться с потребностями- где нужна куча, а где -нет.

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

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

ON> А если это все-таки работает без проблем, то какая разница? "Вам шашечки, ON> или ехать? (с)-анекдот.

ON>>> А управлять чем-то на другом конце ON>>> земного шара- это экзотика BB>> Роутер Циско это экзотика? Мониторится и настраивается с любого конца BB>> Земного шара.

ON> Я не в курсе столь длинных дистанций.

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

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

BB>> В принципе есть (были?) микросхемы, которые обеспечивали четыре BB>> одновременных соединений TCP/IP. Сам я не применял, только слышал. BB>> Производитель чуть ли не Casio. Hадо искать в гугле на слова "аппаратный BB>> стек TCP/IP". Ставьте такую и будет счастье.

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

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

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