MMU

28 Feb 07 19:40, Michael Mamaev ÐÉÓÁÌ Alex Mogilnikov:

MM> á ÎÅÌØÚÑ ÌÉ y×ÉÄÅÔØ ÂÏÌÅÅ-ÍÅÎÅÅ ×ÍÅÎÑÅÍyÀ ÜÈÏÔÁÖÎyÀ pÅÁÌÉÚÁÃÉÀ TCP/IP MM> × ÉÓÈÏÄÎÉËÁÈ, ÄÁ ÅÝÅ É ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ËyÞÉ?

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> мне на слово, что у меня такая есть и используется.

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

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

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 отлично реализуется в однозадачном мониторе. :-)

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> отдельная задача. Она в-основном очередь приема разбирает.

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

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

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

01 Mar 07 10:46, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

BB> åÓÌÉ ÎÅ ÓÅËÒÅÔ, ËÁË ÒÅÁÌÉÚÏ×ÁÎÁ ÓÂÏÒËÁ ÐÁËÅÔÏ× ÎÁ ÐÒÅÍÅ ÉÚ ËÕÓËÏ× BB> ÒÁÚÎÏÊ ÄÌÉÎÙ? :-)

HÉËÁË. ðÏËÁ ÅÝÅ ÎÉ × ÏÄÎÏÍ ÉÚ ÐÒÉÍÅÎÅÎÉÊ ÔÁËÏÊ ÆÕÎËÃÉÏÎÁÌØÎÏÓÔÉ ÎÅ ÐÏÔÒÅÂÏ×ÁÌÏÓØ. ÷ÓÅ ÐÁËÅÔÙ ÕËÌÁÄÙ×ÁÀÔÓÑ × 1500 ÂÁÊÔ. õ ÍÅÎÑ ÄÁÖÅ ÎÁ ÐÅÒÓÏÎÁÌËÅ ÄÏÌÇÏÅ ×ÒÅÍÑ (ÇÏÄÙ) ÂÙÌÏ ÐÒÏÐÉÓÁÎÏ deny ip from any to any frag...

BB> åÝÅ ×ÏÐÒÏÓ - ÉÓÐÏÌØÚÕÅÔÓÑ ÌÉ ÛÅÄÕÌÅÒ? éÌÉ ×ÓÅ ËÒÕÔÉÔÓÑ × ÏÄÎÏÊ ÚÁÄÁÞÅ BB> - ÇÌÁ×ÎÏÍ ÃÉËÌÅ?

01 Mar 07 10:52, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

BB> á ÔÏ ÍÎÅ ÔÕÔ × ÏÄÎÏÍ ÍÅÓÔÅ ÎÁ ÐÏÌÎÏÍ ÓÅÒØÅÚÅ ×ÔÉÒÁÌÉ, BB> ÞÔÏ TCP/IP ÏÔÌÉÞÎÏ ÒÅÁÌÉÚÕÅÔÓÑ × ÏÄÎÏÚÁÄÁÞÎÏÍ ÍÏÎÉÔÏÒÅ. :-)

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

Hello Basil!

BB> åÝÅ ×ÏÐÒÏÓ - ÉÓÐÏÌØÚÕÅÔÓÑ ÌÉ ÛÅÄÕÌÅÒ? éÌÉ ×ÓÅ ËÒÕÔÉÔÓÑ × ÏÄÎÏÊ ÚÁÄÁÞÅ BB> - ÇÌÁ×ÎÏÍ ÃÉËÌÅ? á ÔÏ ÍÎÅ ÔÕÔ × ÏÄÎÏÍ ÍÅÓÔÅ ÎÁ ÐÏÌÎÏÍ ÓÅÒØÅÚÅ ×ÔÉÒÁÌÉ, BB> ÞÔÏ TCP/IP ÏÔÌÉÞÎÏ ÒÅÁÌÉÚÕÅÔÓÑ × ÏÄÎÏÚÁÄÁÞÎÏÍ ÍÏÎÉÔÏÒÅ. :-)

MS-DOS ÐÏÊÄÅÔ ËÁË ÐÒÉÍÅÒ ÏÄÎÏÚÁÄÁÞÎÏÇÏ ÍÏÎÉÔÏÒÁ? :-)

Sergei

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) такое вполне может быть. А у Вас тлько один статический буфер для сборки пакетов и нет возможности запросить новый буфер и начать сборку второго пакета, не собрав первый.

01 Mar 07 13:25, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

AM>> õ ÍÅÎÑ ÄÁÖÅ ÎÁ ÐÅÒÓÏÎÁÌËÅ ÄÏÌÇÏÅ ×ÒÅÍÑ (ÇÏÄÙ) ÂÙÌÏ AM>> ÐÒÏÐÉÓÁÎÏ deny ip from any to any frag...

BB> äÁ, ÔÁË ÞÁÓÔÏ ÄÅÌÁÀÔ. ïÓÏÂÅÎÎÏ ÄÌÑ ÐÒÉÍÅÎÅÎÉÊ, ËÏÔÏÒÙÅ ÏÂÝÁÀÔÓÑ ÔÏÌØËÏ BB> ×ÎÕÔÒÉ ÏÄÎÏÊ ÅÚÅÒÎÅÔÏ×ÓËÏÊ ÌÏËÁÌËÉ.

BB> ïÄÎÁËÏ, ËÁË ÷Ù ÓÁÍÉ ÐÏÎÉÍÁÅÔÅ, ÔÁËÏÅ BB> ÒÅÛÅÎÉÅ ÎÉËÁË ÎÅÌØÚÑ ÎÁÚ×ÁÔØ "ÐÏÌÎÏÃÅÎÎÏÊ ÒÅÁÌÉÚÁÃÉÅÊ TCP/IP". óËÏÒÅÅ BB> ÜÔÏ "ÓÒÅÄÓÔ×Ï ÐÅÒÅÐÉÈÎÕÔØÓÑ ÐÏ UDP × ÐÒÅÄÅÌÁÈ ÌÏËÁÌËÉ".

HÅ ÓÏÇÌÁÓÅÎ. ÷Ï-ÐÅÒ×ÙÈ, ÎÅ ÏÂÑÚÁÔÅÌØÎÏ × ÌÏËÁÌËÅ. áÐÐÁÒÁÔÕÒÁ ÒÅÁÌØÎÏ ÒÁÂÏÔÁÅÔ × ÄÏ×ÏÌØÎÏ ÐÒÏÔÑÖÅÎÎÙÈ É ÒÁÚ×ÅÔ×ÌÅÎÎÙÈ ÓÅÔÑÈ. ÷Ï-×ÔÏÒÙÈ, ÉÚ ×ÓÅÈ ÐÒÏÔÏËÏÌÏ×, Ó ËÏÔÏÒÙÍÉ ÍÎÅ ÐÒÉÈÏÄÉÌÏÓØ ÉÍÅÔØ ÄÅÌÏ, ÍÎÏÇÏËÉÌÏÂÁÊÔÎÙÅ UDP ÐÁËÅÔÙ ÉÓÐÏÌØÚÕÀÔÓÑ ÔÏÌØËÏ × NFS. ðÏ ËÒÁÊÎÅÊ ÍÅÒÅ, ÄÌÑ ÜÈÏÔÁÇÁ, ÒÁÚÂÏÒËÁ ÂÏÌØÛÉÈ ÐÁËÅÔÏ× ÎÁ ÆÒÁÇÍÅÎÔÙ - ÓËÏÒÅÅ ÜËÚÏÔÉËÁ ÞÅÍ ÐÒÁ×ÉÌÏ. äÌÑ TCP ÖÅ, ÎÁÓËÏÌØËÏ Ñ ÚÎÁÀ, ÄÁÖÅ ÅÓÌÉ ÎÅ ÉÓÐÏÌØÚÕÅÔÓÑ PMTUD, ÐÒÉ ËÏÔÏÒÏÍ ÐÁËÅÔÙ ×ÏÏÂÝÅ ÉÄÕÔ Ó ÆÌÁÇÏÍ DF, ÅÓÔØ ÐÒÉÓÌÁÎÎÙÊ Ó ÄÒÕÇÏÊ ÓÔÏÒÏÎÙ MSS...

BB> HÁÐÒÉÍÅÒ, Ó×ÑÚÎÏÅ BB> ÓÅÔÅ×ÏÅ ÏÂÏÒÕÄÏ×ÁÎÉÅ ÐÏÞÔÉ ×ÓÅÇÄÁ ÉÍÅÅÔ ÔÅÈÎÏÌÏÇÉÞÅÓËÉÊ ËÁÎÁÌ BB> ÄÌÑ ÍÏÎÉÔÏÒÉÎÇÁ É ÎÁÓÔÒÏÅË. åÓÌÉ ÐÒÏÉÚ×ÏÄÉÔÅÌØ, ËÁË ÞÁÓÔÏ ÂÙ×ÁÅÔ, BB> ÎÁÈÏÄÉÔÓÑ × ôÁÊÂÅÅ :-), Á ÁÐÐÁÒÁÔÕÒÁ ÓÔÏÉÔ ÎÁ ëÁÍÞÁÔËÅ, ÔÏ ÔÅÈÓÁÐÐÏÒÔ BB> ÔÅÏÒÅÔÉÞÅÓËÉ ÍÏÖÎÏ ÏÓÕÝÅÓÔ×ÌÑÔØ ÕÄÁÌÅÎÎÏ. HÏ ÅÓÌÉ ÒÅÁÌÉÚÁÃÉÑ TCP/IP ÎÅ BB> ÐÏÄÄÅÒÖÉ×ÁÅÔ ÓÂÏÒËÕ ÆÒÁÇÍÅÎÔÉÒÏ×ÁÎÎÙÈ ÐÁËÅÔÏ×, Á ÎÁ ÐÕÔÉ ÏÔ ôÁÊÂÅÑ ÄÏ BB> ëÁÍÞÁÔËÉ ÐÒÏÌÏÖÅÎÁ ÌÉÎÉÑ Ó ÍÁËÓÉÍÁÌØÎÙÍ ÒÁÚÍÅÒÏÍ ÐÁËÅÔÁ ÍÅÎØÛÅ, ÞÅÍ × BB> ÅÚÅÒÎÅÔÅ, ÔÏ ÎÅÓÍÏÔÒÑ ÎÁ ÉÓÐÒÁ×ÎÏÓÔØ ×ÓÅÈ ÔÅÈÎÉÞÅÓËÉÈ ÓÒÅÄÓÔ× Ó×ÑÚÉ BB> ÐÏÌÕÞÉÔØ ÎÅ ÕÄÁÓÔØÓÑ.

01 Mar 07 13:31, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

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

BB> ôÏ ÅÓÔØ ÐÁËÅÔ ÄÏÌÖÅÎ BB> ÂÙÔØ ÐÒÉÎÑÔ ÓÒÁÚÕ É ÃÅÌÉËÏÍ. ôÏ ÅÓÔØ ÜÔÏ ÏÐÑÔØ UDP, Á Á ×Ï×ÓÅ ÎÅ BB> TCP/IP.

? ÷ ÍÏÅÊ ÐÒÁËÔÉËÅ ÅÓÌÉ É ×ÓÔÒÅÞÁÀÔÓÑ ÆÒÁÇÍÅÎÔÉÒÏ×ÁÎÎÙÅ ÐÁËÅÔÙ, ÔÏ ÜÔÏ ÉÍÅÎÎÏ UDP, Á ÎÅ TCP. ÷ÓÔÒÅÞÁÀÔÓÑ ÏÎÉ ÍÎÅ × NFS. äÌÑ TCP ÏÔÓÕÔÓÔ×ÉÅ ÆÒÁÇÍÅÎÔÁÃÉÉ ÏÂÅÓÐÅÞÉ×ÁÅÔ PMTUD. HÕ ×ÏÔ ÓÅÊÞÁÓ ÓÐÅÃÉÁÌØÎÏ ÐÕÓÔÉÌ tcpdump ÎÁ ÍÁÒÛÒÕÔÉÚÁÔÏÒÅ, ÞÅÒÅÚ ËÏÔÏÒÙÊ ÎÁÛÁ ÆÉÒÍÁ Ë ÉÎÔÅÒÎÅÔÕ ÐÏÄËÌÀÞÅÎÁ - ÁÂÓÏÌÀÔÎÏ ÎÁ ×ÓÅÈ TCP ÐÁËÅÔÁÈ, ËÏÔÏÒÙÅ Ñ ×ÉÖÕ, ÓÔÏÉÔ DF. ÷ÏÔ Õ×ÉÄÅÌ ÔÏÌØËÏ ÏÄÉÎ ÐÁËÅÔ ÂÅÚ DF

- ÜÔÏ ÂÙÌ TCP RESET. :)

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

for(;;) { packet = net_rx_queue.pend(); net_process(packet); }

for(;;) { packet = net.rx_queue.empty() ? NULL : net_rx_queue.get(); net_process(packet);

{ // ÄÅÌÁÅÍ ×ÓÅ ÏÓÔÁÌØÎÏÅ } }

01 Mar 07 17:47, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

AM>> ÷ÅÒÎÏ. ôÏÌØËÏ Ë ÉÓÐÏÌØÚÏ×ÁÎÉÀ ËÕÞÉ ÜÔÏ ÎÅ ÉÍÅÅÔ ÏÔÎÏÛÅÎÉÑ. AM>> ðÁËÅÔ ÒÁÚÍÅÒÏÍ ÄÏ 1500 ÂÁÊÔ ÍÏÖÅÔ ÂÙÔØ ÓÏÂÒÁÎ ÉÚ ÆÒÁÇÍÅÎÔÏ× × AM>> ÏÄÎÏÍ ÆÉËÓÉÒÏ×ÁÎÎÏÍ ÂÕÆÅÒÅ.

BB> á ÅÓÌÉ ÞÁÓÔØ ×ÔÏÒÏÇÏ ÐÁËÅÔÁ ÄÌÑ ÜÔÏÇÏ ÖÅ ÓÏÅÄÉÎÅÎÉÑ ÐÒÉÛÌÁ ÒÁÎØÛÅ, ÞÅÍ BB> ÓÏÂÒÁÌÓÑ ÐÅÒ×ÙÊ ÐÁËÅÔ? ðÏ ÓÐÅÃÉÆÉËÁÃÉÉ ÄÁÖÅ UDP (Á ÔÅÍ ÂÏÌÅÅ TCP/IP) BB> ÔÁËÏÅ ×ÐÏÌÎÅ ÍÏÖÅÔ ÂÙÔØ.

BB> á Õ ÷ÁÓ ÔÌØËÏ ÏÄÉÎ ÓÔÁÔÉÞÅÓËÉÊ ÂÕÆÅÒ ÄÌÑ

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

? úÁÞÅÍ ÔÁËÏÊ ÜËÓÔÒÅÍÉÚÍ - _ÔÏÌØËÏ_ ÏÄÉÎ ÂÕÆÅÒ? :))) óËÏÌØËÏ ÔÒÅÂÕÅÔÓÑ - ÓÔÏÌØËÏ É ÎÁÄÏ ÂÒÁÔØ. ó ÒÁÚÕÍÎÙÍÉ ÏÇÒÁÎÉÞÅÎÉÑÍÉ, ËÏÎÅÞÎÏ. ñ ÉÍÅÌ × ×ÉÄÕ, ÞÔÏ ÂÕÆÅÒÁ ÆÉËÓÉÒÏ×ÁÎÎÏÇÏ ÒÁÚÍÅÒÁ ÂÕÄÅÔ ÄÏÓÔÁÔÏÞÎÏ ÄÌÑ ÓÂÏÒËÉ ÏÄÎÏÇÏ ÐÏÌÎÏÇÏ ÐÁËÅÔÁ, É ÎÅÏÂÈÏÄÉÍÏÓÔÉ ×ÙÄÅÌÑÔØ ÐÁÍÑÔØ ÉÚ ËÕÞÉ ÎÅÔ.

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> Попкина.

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

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

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

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

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

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

02 Mar 07 17:26, Basil Burtakov ÐÉÓÁÌ Alex Mogilnikov:

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

- 24 ÞÁÓÁ × ÓÕÔËÉ É 7 ÄÎÅÊ × ÎÅÄÅÌÀ.

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

Hello Basil!

Roman

... So far, so good... so what ?

Basil Burtakov пишет:

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

MM>> á ÎÅÌØÚÑ ÌÉ y×ÉÄÅÔØ ÂÏÌÅÅ-ÍÅÎÅÅ ×ÍÅÎÑÅÍyÀ ÜÈÏÔÁÖÎyÀ pÅÁÌÉÚÁÃÉÀ MM>> TCP/IP × ÉÓÈÏÄÎÉËÁÈ, ÄÁ ÅÝÅ É ÂÅÚ ÉÓÐÏÌØÚÏ×ÁÎÉÑ ËyÞÉ? AM> åÓÌÉ ×ÏÐpÏÓ ËÏÎËpÅÔÎÏ ËÏ ÍÎÅ, ÔÏ y×ÉÄÅÔØ ÎÅÌØÚÑ. ðpÅÄÌÁÇÁÀ AM> ÐÏ×ÅpÉÔØ ÍÎÅ ÎÁ ÓÌÏ×Ï, ÞÔÏ y ÍÅÎÑ ÔÁËÁÑ ÅÓÔØ É ÉÓÐÏÌØÚyÅÔÓÑ.

íÁÊËÌ