Страниц: 1 [2] 3
  Печать  
Автор Тема: Чтение всех данных из сети  (Прочитано 15822 раз)
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #15 : Июня 30, 2005, 04:00:55 pm »

ksv
Много читаем документацию, экспериментируем, не забываем про флаги _NPKT_MSG...
Следим за количеством памяти io-net при невызове tx_done() при продвижении пакета вверх.

/me whispers friendly: И не говорим глупостей.
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #16 : Июня 30, 2005, 04:15:37 pm »

pvk
Сегодня принес, но еще не выложил - я толдько появился на работе и у меня проблемы с ISP.
Завтра с утра качайте наздоровье.

ksv
Скачайте код nfm-ntc и посмотрите, как там все реализовано. ОСОБЕННО ОБРАТИТЕ ВНИМАНИЕ НА ОБРАБОТКУ ПАКЕТОВ С _NPKT_MSG - как они обрабатываются и никогда не попадают в ntc_capture().
Почитайте еще раз доку из комплекта Networking DDK. Если у вас есть сам DDK то посмотрите, как реализована передача пакета от драйвера вверх по иерархии.

И все-таки, прежде чем возражать, сделайте простой дампер того, что происходит в вашем модуле... типа fprintf() в лог файл.
Записан
pvk
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #17 : Июня 30, 2005, 04:19:23 pm »

To MikeP:
при невызове tx_done() после каждого tx_up() ничего с памятью io-net не происходит.
Вызов tx_done() у меня аналогичен тому, как указал ksv.
Кстати, ksv, вы это по собственному опыту сделали или еще почему?

Зато в этом случае io-net не падаем фиг знает от чего.
Записан
ksv
Участник
*
Offline Offline

Сообщений: 10


Просмотр профиля
« Ответ #18 : Июня 30, 2005, 04:28:28 pm »

To MikeP:
Вам же pvk русским языком объяснил, что ваш nfm-ntc снимает io-net по SIGSEGV, так что читать документацию по io-net и за "количеством памяти" нужно следить не мне, а Вам. И к замечаниям советую прислушиваться, а не рыть копытом землю.

  Если бы предлагаемый вариант не был мною неоднократно испытан и проверен, я бы здесь его не предлагал.
Записан
ksv
Участник
*
Offline Offline

Сообщений: 10


Просмотр профиля
« Ответ #19 : Июня 30, 2005, 04:38:04 pm »

pvk
Кстати, ksv, вы это по собственному опыту сделали или еще почему?


Это мне стоило нескольких месяцев жизни (в смысле работы). Мною был разработан полный спектр dll-модулей io-net для реализации специализированного протокола(список я перечислил в предыдущем посте), который круглосуточно работает около года (начинал еще с 6.2.0, теперь вот на 6.3).
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #20 : Июня 30, 2005, 05:44:08 pm »

Право рыть копытом землю все-таки оставляю за собой...
Проект, побочным результатом которого является nfm-ntc работает без всяких проблем. Написан в точном соответствии с Networking DDK. Падений в проекте не наблюдалось ни разу... тем более по SIGSEGV. Это, уж извините, руки из нетого места расти должны....
Модуль представляет собой фильтр пакетов, основанный на рассмотрении MAC адресов. Работает вот уже с пол года (если точнее - то с 11 декабря 2004 года)без перезапусков.
Без проблем считает трафик по MAC адресам и занимается примерно тем, чем занимается SNORT.
Кроме того, мной разработаны модули к io-net:
devn-vpn.so - модуль, выступающий в качестве сервера PPtP и PPPoE, позволяющий кроме всего прочего производить учет трафика пользователей как в RADIUS так и в родном формате в связке с Q-base.
nfm-firewall - позволяющий реализовать фильтрацию IP трафика по правилам, очень напоминабщим IPFilter. Единственное, чего я не смог - это сделать NAT - для этого необходимо замапленый порт для клиента обозначать как занятый в TCP или UDP стеке. Как это сделать - я не знал. Потому и не доделал.

НИКОГДА, СЛЫШИТЕ, НИКОГДА не ройте копытом землю сами. К чести QSSL, если в их документации и встречаются неточности, то это довольно редко. Я разбирался с io-net исключительно по DDK и HELP. Провел множество экспериментов и терзал сначала 6.2.1 потом 6.2.1B и только недавно 6.2SP1.
Ни на одной из систем у меня не было проблем с моими модулями. Последняя их версия работает без перезапуска на машине с 6.2.1B c 11 декабря 2004 года.

Единственное отличие между мной и pvk в том, что я работаю исключительно на x86, а он собирает на Arm BE.
Я никогда не работал с Arm, но слышал краем уха про его плохую реакцию на обращения по невыровненным адресам в памяти, коих в nfm-ntc - вполне достаточно.

Кстати, nfm-ntc замечательно работает. Уважаемый правдоруб, предлагаю вам скачать это детище и попробовать попользовать. Если оно у вас упадет и вы представите причины его падения, я сниму перед вами шляпу. На сколько я понимаю io-net_g у вас имеется? DDK тоже... Тогда вперед - на встречу заре! ДОКАЖИТЕ СВОЮ ПРАВОТУ!

С нетерпением ждущий ответа, слегка напраздновавшийся,
и искренне уважающий окружающих
MikeP
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #21 : Июня 30, 2005, 05:47:29 pm »

Сорри, в вышестоящем посте конечно же имеется в виду 6.3SP1 в предложении про мои изголения над QNX.
Записан
pvk
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #22 : Июля 01, 2005, 07:51:17 am »

MikeP:
Я искренне уважаю ваш опыт по io-net и ваш труд в лице nfm-ntc. Просто у меня возникла проблема с этой библиотекой, и я стал разбираться.
Установил, что io-net не падает, когда он запущен без tcpip и падает, соот-но, когда tcpip запущен. Почитав доки я где-то нашел, что tx_done вызывается не после каждого tx_up, а только когда он <= 0. Попробовал - перестало падать.
Я верю, что это у вас работает очень давно и исправно, но и мне бы тоже так хотелось

Возможно, проблема в armbe. Но мож тогда кто подскажет, хотя бы примерно, в чем она может заключаться и как с этим бороться. Может использовать __attribute__ packed, может еще что.
Был бы очень благодарен.
Записан
pvk
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #23 : Июля 01, 2005, 07:56:10 am »

MikeP:
Откуда сегодня утром (т.е. сейчас) можно качать?
Записан
ksv
Участник
*
Offline Offline

Сообщений: 10


Просмотр профиля
« Ответ #24 : Июля 01, 2005, 12:07:20 pm »

MikeP
Кстати, nfm-ntc замечательно работает. Уважаемый правдоруб, предлагаю вам скачать это детище и попробовать попользовать. Если оно у вас упадет и вы представите причины его падения, я сниму перед вами шляпу. На сколько я понимаю io-net_g у вас имеется? DDK тоже... Тогда вперед - на встречу заре! ДОКАЖИТЕ СВОЮ ПРАВОТУ!

  Уважаемый MikeP, к сожалению должен Вас огорчить - я не собираюсь записываться в команду beta-тестеров и отлаживать Ваши "побочные результаты", иначе не останется времени на поиск своих ошибок.

  Я всего лишь искренне хотел помочь pvk советом, и насколько понял из его постов, это у меня получилось.

  А если Вы, вчера "слегка напраздновавшийся", сегодня с утра сидите с открытой бутылкой пива возле монитора, то подвигайтесь к нему поближе и, широко раскрыв глаза и уши, слушайте сказку про тридевятое царство под названием io-net:

Вначале вспомним назначение функции tx_done():
1. Вызывается для downward-пакетов один раз в модуле, который получает этот пакет последним в цепочке DOWN_PRODUCER->DOWN_FILTER->CONVERTER->UP_FILTER->UP_PRODUCER. В общем случае - это модуль драйвера сетевой карты.
Это приводит к последовательному вызову в LIFO-порядке функций tx_done() из состава тех модулей, через которые передавался пакет.
Задача этих функций - удалить из пакета ту часть данных, которая могла быть добавлена функцией rx_down() этого же модуля. Например, заголовок протокола более низкого уровня в начале пакета или байты вычисленной контрольной суммы в конце пакета.
Таким образом каждый модуль удаляет из пакета только те поля, которые он добавил. Самый верхний модуль (DOWN_PRODUCER), который инициировал передачу этого пакета получает его (в своей функции tx_done()) уже без посторонних полей в первозданном виде. Далее, в зависимости от своего сценария, этот пакет может быть удален, либо поставлен в пул свободных пакетов и использоваться в дальнейшем повторно для передачи последующих сообщений.

2. Вызывается для upward-пакетов тоже один раз, но только тем модулем из цепочки UP_PRODUCER->UP_FILTER->CONVERTER->DOWN_FILTER->DOWN_PRODUCER, который принял решение об окончании обработки этого пакета и отсутствия необходимости передавать этот пакет вышестоящим модулям. Либо при попытке передачи этого пакета функцией tx_up() (внутри функции rx_up() очередного модуля) возникла ошибка или было обнаружено, что этот пакет не был обработан ни одним из вышестоящих модулей (tx_up() вернул 0). В этом случае ответственность за своевременное удаление пакета берет на себя этот промежуточный модуль и путем вызова tx_done() он сообщает через io-net модулю UP_PRODUCER (драйверу сетевой карты) о том, что обработка этого пакета окончена. Функция tx_done() модуля UP_PRODUCER, опять же в зависимости от своей стратегии работы, либо возвращает этот пакет в пул готовых к повторному использованию, либо если их там достаточно, просто его удаляет.

А теперь посмотрим, что происходит с пакетом при его передаче от UP_PRODUCER к вышестоящим модулям:

UP_PRODUCER:
up_producer_receive()
{
...
if(npkt = ion->tx_up_start())
up_producer_tx_done();

return 0;
}

UP_FILTER:
CONVERTER:
DOWN_FILTER:
rx_up()
{
...

pass = capture();
if(pass == 0)
{
if( ion->tx_up() <= 0 )
ion->tx_done(); // возвращаем необработанный пакет
}
else
ion->tx_done();  // возвращаем отфильтрованный пакет

return 0;
}

DOWN_PRODUCER:
rx_up()
{
... // обработка пакета

ion->tx_done(); // возвращаем обработанный пакет

return 0;
}

Это простейший сценарий. Может возникнуть необходимость задержать пакет в UP_PRODUCER до того момента, когда за ним обратится клиентский процесс. В этом случае пакет накапливается в очереди принятых и tx_done() для него вызывается уже в потоке обработки клиентских запросов к менеджеру ресурсов, реализованному внутри модуля UP_PRODUCER.

MikeP
Это, уж извините, руки из нетого места расти должны....

Прежде чем обсуждать чужие руки, нужно сначала посмотреть на свои...

MikeP
Я никогда не работал с Arm, но слышал краем уха про его плохую реакцию на обращения по невыровненным адресам в памяти, коих в nfm-ntc - вполне достаточно.

Cчитаю списывание ошибок на компилятор при выравнивании неуместным, т.к. при моем варианте, после того-же самого компилятора io-net не падает.

pvk
Установил, что io-net не падает, когда он запущен без tcpip и падает, соот-но, когда tcpip запущен.

  Этим косвенно подтверждается мой довод, о том что tx_done() для upward-пакетов должен вызываться только один раз. В этом случае пакет пытаются удалить дважды (сначала в модуле nfm-ntc, а затем в модуле протокола tcpip), что и приводит к падению io-net.

to MikeP:
  Насколько я понял из перечисления разработанных Вами модулей, Вам никогда не приходилось иметь дело с полным стеком используемых модулей, а обрабатывать в основном входящий трафик (т.е. upward).

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

PS А рыть копытом землю можете, но только где-нибудь на заднем дворе, что-бы не испортить асфальт перед парадным входом здания под названием QNX.

С уважением к Вашим разработкам, ksv
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #25 : Июля 01, 2005, 01:43:39 pm »

Итак, начнем по порядку.
С лирического вступления - празднование не подразумевает упитие в хлам и посиделки с бутылкой пива у монитора и т.п. Оставим все выше сказанное на совести вашего воображения.

2)По поводу сказок про тридевятое царство:
Читаем документацию по tx_done():
- что касается нисходящих пакетов - сказку вы пересказали верно.
теперь обратимся к тому, что ползет вверх:
Вот отсюдачки.
http://www.qnx.com/developers/docs/momentics621_docs/ddk_en/network/io_net_self_t.html#tx_  done


For upward-headed packets, this function is called by each module (including the originator) when finished with the packet. The single tx_done() stored in the packet is called when the ref_cnt member goes to zero.

This function returns:
0
Success.
-1
An error occurred; errno is set.


Переводить нужно?

ksv

Вызывается для upward-пакетов тоже один раз, но только тем модулем из цепочки UP_PRODUCER->UP_FILTER->CONVERTER->DOWN_FILTER->DOWN_PRODUCER,

Не буду вам разъяснять в подробностях вашу ошибку, но вот такая последовательность передачи пакетов не может возникнуть НИКОГДА. Производитель пакетов "вниз" никогда не получит от io-net пакет, если конечно модуль не зарегистрировал себя как что-то еще. Все, что регистрируется как DOWN_* не получит восходящих пакетов.

ksv

Этим косвенно подтверждается мой довод, о том что tx_done() для upward-пакетов должен вызываться только один раз. В этом случае пакет пытаются удалить дважды (сначала в модуле nfm-ntc, а затем в модуле протокола tcpip), что и приводит к падению io-net.


а) это только догадки, дебагером человек не воспользовался.
б) советую научиться пользоваться дебагером вам, ksv, ибо только так вы узнаете, что tx_done() сначала вызывается в npm-tcpip, и только потом в нижестоящих модулях (nfm-ntc в частности). Удаляется пакет только тогда, когда его источник (т.е. REG_PRODUCER_UP) вызовет tx_done() после передачи пакета. Только тогда будет вызвана tx_done(), единственная зарегистрированная этим самым продюсером. И уже внутри собственной зарегистрированной tx_done() он сможет буфер пакета вернуть себе в очередь или просто уничтожить.

ksv

to MikeP:
Насколько я понял из перечисления разработанных Вами модулей, Вам никогда не приходилось иметь дело с полным стеком используемых модулей, а обрабатывать в основном входящий трафик (т.е. upward).


Плохо читаете или туго с понималкой. Для тренировки и прибавления серого вещества можно решать простенькие задачки. Например, как реализовать стек протоколов PPP так, чтобы получить неограниченное количество виртуальных адаптеров, в которые пакеты попадают из npm-tcpip и на выходе возвращаются в (о ужас!) в него же (в npm-tcpip - это для облегчения понимания)!

Придержите своё бахвальство для кого-нибудь еще. Прочтите, наконец, документацию. Прочитаете, если не побрезгуете, мою статью в книжке и может тогда наберетесь ума. Я представил к статье и фильтр, и драйвер, которые работают. Без падений по SIGSEGV. Не грешу ни на что, но неоднократно советовал pvk попользоваться дебагером.
Не делайте голословных выводов на основании совершенно неочевидных внешних проявлений падения программы - еще не известно, в каком месте падает io-net. И в догонку - tx_done() из io_net_self_t НИКОГДА НИЧЕГО НЕ ОСВОБОЖДАЕТ и изменить указатель принципиально не может - SIGSEGV не из-за количества вызовов tx_done().

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

P.S.
2 pvk
Раз пошла такая пьянка - новую версию nfm-ntc я убираю со своего сайта. Делаю это не из обиды, а для того, чтобы вы сами сделали свой модуль к io-net, прочли документацию и с дебагером в зубах уяснили, как работает io-net. Сделали все САМОСТОЯТЕЛЬНО. Это лучше, чем слушать бесполезные споры и ждать, что кто-то ниспошлет верное решение. Для начала у вас есть костяк.
Желаю удачи в работе.
Записан
pvk
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #26 : Июля 01, 2005, 02:15:12 pm »

2 MikeP
Дело конечно ваше, дать кому-то вашу библиотеку или нет. Просто странно: вы говорите, что убрали ее не из обиды - имхо на меня обижаться не за что, я вас ничем не оскорблял и не обижал, я лишь попросил помочь разобраться и вы (неделю назад) обещали мне вашу новую библиотеку.
Естественно, я разберусь, прочту документация, сделаю все САМОСТОЯТЕЛЬНО. Просто как и любому программисту, на все нужно время, а его всегда не хватает.
Но я нисколько НЕ ЖДАЛ ниспослания на меня верного решения, как выразились вы. Я просто попросил ПОМОЧЬ разобраться в моей проблеме, и все.

А за костяк спасибо, он мне действительно помог.
А вашу статью в книжке еще неизвестно когда можно будет прочесть, так что пока мне от нее толков мало.
Записан
MikeP
Участник
*
Offline Offline

Сообщений: 6


Просмотр профиля WWW
« Ответ #27 : Июля 01, 2005, 02:29:58 pm »

pvk
Обида не на вас, а на личности, делающие голословные выпады. Нисколько не сомневался, что вы в состоянии сделать все самостоятельно. Это правильно.
Напишите мне письмо - я не помню ваш адрес. Могу дать вам статью под NDA. Там подробное описание и в тексте код последней версии nfm-ntc и драйвера devn-ser.

Извините, если заставил думать, что настроен против вас
Записан
pvk
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #28 : Июля 01, 2005, 03:00:13 pm »

MikeP
Письмо написал, буду благодарен за любую информацию о io-net и драйверах под него.

ksv
Спасибо вам за участие в моей проблеме.

All
Имхо форум нужен не для выяснения крутости, а для помощи другим людям. Если не так - поправьте
Записан
ksv
Участник
*
Offline Offline

Сообщений: 10


Просмотр профиля
« Ответ #29 : Июля 01, 2005, 03:56:06 pm »

pvk
All
Имхо форум нужен не для выяснения крутости, а для помощи другим людям. Если не так - поправьте.

Полностью согласен, об этом я и говорил:
ksv
Я всего лишь искренне хотел помочь pvk советом, и насколько понял из его постов, это у меня получилось.

Привожу пост из конференции qdn.public.ddk.network в котором сотрудник QSSL объясняет все ясно и понятно. Если для MikeP и это мнение не является авторитетным, предлагаю ему обратится к Xiaodan Tang - разработчику io-net.

Shaun Jackman <sjackman@nospam.vortek.com> wrote:
: From the DDK docs I read the following:
:> For upward-headed packets, this function is called by each module
: (including the originator) when finished with the packet.
: For purposes of memory management, is a filter not considered a module? Do
: only leaf modules (those that haven't forwarded the packet)tx_done() the
: packet?

A filter is a module.  All modules need to call tx_done() on up
headed packets in the manner I laid out below.

: By contract, calling tx_done() on a packet means you won't inspect any
: memory associated with that packet thereafter. Does calling tx_up() on a
: packet imply the same thing?

Yes.  Calling tx_done() on the packet means you're done with it.  If you
pass it up, you should also be done with it.  Recall, you need to look
at the return code of tx_up() to see if you need to call tx_done().
Something like:

if(you_decide_not_to_pass_it_up) {
    ion->tx_done(hdl, npkt);
}
else {
   if(ion->tx_up(reg_hdl, npkt, ...) == 0)
        ion->tx_done(hdl, npkt);
}


-seanb

: Cheers,
: Shaun

: Sean Boudreau <seanb@qnx.com> wrote in message
: news:adj2kl$j09$1@nntp.qnx.com...
:>
:> It's up to you whether or not you pass them up.  Obviously,
:> the upper layers won't work very well if you send all of them
:> to the bit bucket.
:>
:> You call tx_done() on up headed packets if no one above you takes
:> them. ie if you don't call ion->tx_up on the packet, or if
:> ion->tx_up() returns 0.

:>
:> -seanb
:>
:> Shaun Jackman <sjackman@nospam.vortek.com> wrote:
:> : I'm writing an up filter. When I receive a packet through rx_up(), after
: I'm
:> : done with the packet am I expected to tx_up() the packet up to the next
:> : layer? I always tx_done() every packet I receive (correct?). If I am
:> : expected to forward packets, does this include NPKT_MSG packets, such
:> : MSG_DL_ADVERT packets?
:>
:> : Thanks,
:> : Shaun
:>
:>
:>
Записан
Страниц: 1 [2] 3
  Печать  
 
Перейти в: