Board.KolibriOS.org

Я начала создавать библиотеку для работы с сетью. Первая версия экспортирует стандартные функции inet_ntoa, inet_addr, getaddrinfo, freeaddrinfo для работы с доменными именами, информацию о функциях легко найти в Сети, в стандарте POSIX, в MSDN или в манах. getaddrinfo не поддерживает IPv6 и сырые сокеты, не поддерживает файлы hosts и services, так что имя службы можно указывать только в десятичной нотации или не указывать вовсе. Резолвинг имён поддерживается полностью. Кеширования DNS-ответов пока нет, но, по крайней мере, общесистемный кеш можно сделать, если приложения будут использовать библиотеку вместо того, чтобы отправлять запросы вручную.
Библиотека работает только со свежим ядром: в ревизии 1153 я добавила возвращаемое значение к функции 40, в ревизии 1154 - выбор неиспользованного локального порта при указании нуля в функциях открытия сокета.
Функция getaddrinfo может заморозить вызывающий поток, ожидая ответа от DNS-сервера. Для того, чтобы в процессе ожидания можно было ещё что-то делать, например, обрабатывать события типа перерисовки, есть два варианта. Во-первых, можно создать второй поток, который будет ждать ответа от getaddrinfo, в то время как главный поток может заниматься чем угодно. Во-вторых, я вынесла в экспорт отдельные части: getaddrinfo_start, посылающую запрос, getaddrinfo_process, обрабатывающую результат, и getaddrinfo_abort для прерывания ожидания, например, по таймауту, и вместо одного блокирующего вызова getaddrinfo можно вызвать getaddrinfo_start, после чего в цикле обработки сообщений события с сетью направлять на обработку getaddrinfo_process, а с остальными работать как обычно.
Я закоммитила библиотеку на SVN, в папку svn://kolibrios.org/programs/develop/libraries/network, поэтому исходников здесь не выкладываю. Скомпилированную версию я всё же прилагаю.
В качестве примера использования есть консольный резолвер имён, который в цикле читает доменное имя и выводит все соответствующие ему IP-адреса. Я закоммитила его исходники вместе с библиотекой в подпапку examples, скомпилированную версию тоже прилагаю.

CleverMouse wrote: Во-вторых, я вынесла в экспорт отдельные части: getaddrinfo_start, посылающую запрос, getaddrinfo_process, обрабатывающую результат, и getaddrinfo_abort для прерывания ожидания, например, по таймауту, и вместо одного блокирующего вызова getaddrinfo можно вызвать getaddrinfo_start, после чего в цикле обработки сообщений события с сетью направлять на обработку getaddrinfo_process, а с остальными работать как обычно.

Насколько я понимаю это получается асинхронный режим работы. Замечательно.
Однако я немного не понимаю какой процесс при этом занимается собственно обработкой до установки флага события? Если поток ядра, то не приведет ли дополнительная нагрузка на один поток, при многочисленных запросах от разных приложений, к увеличению значения времени отклика системы в целом, т.е. есть вероятность что система будет подтормаживать?
Поскольку у нас кольцевой линейный планировщик и все процессы равноправны, то приоритет потока ядра мы поднять не можем.

Mario79, я не поняла вопроса. Что ты подразумеваешь под "обработкой до установки флага события"? Физическое чтение пакета из сети и сохранение его в буфер сокета? Такими вещами занимается и должно заниматься ядро, и в Колибри оно обрабатывает сигналы от сетевой платы в главном цикле ядра. Всю остальную обработку делает getaddrinfo_process, когда её позовут, в контексте того потока, который её позовёт.

CleverMouse
Ты все правильно поняла.
Тут скорее вопрос не столько к твоему коду, а сколько к общей организации - ЕМНИП сетеая карта в ядре не повешена на прерывание. Если оно обрабатывается в MAIN LOOP, то пропускная способность сетевого стека весьма низкая, к сожалению.

Mario79, в сетевом стеке авторства hidnplayr, закоммиченном в ветку net репозитория Колибри, сетевая карта всё же "повешена на прерывание".

CleverMouse
1. Мой пост относился к trunk и был размещен здесь раньше, чем появились коммиты от hidnplayr
2. Я знаю о том, что он работал над улучшенным стеком:
Current status of the network stack/network drivers
The new network stack

Скорее всего версия downloader'a от CleverMouse основана на более старой версии downloader'a от barsuk'a, т.к. в ней наблюдается старый глюк - программа не ходит по ссылкам вида http://bash.org.ru/abyssbest и http://bash.org.ru/idea в то время, как на http://bash.org.ru переходит без проблем.

Я прилагаю исправленную версию без глюка, указанного Leency. Кроме исправления глюка, я частично убрала вывод на доску отладки, так что размер несколько уменьшился.

Я добавила в программу обработку ситуаций, при которых HTTP-сервер не указывает явно размер страницы - например, при скачивании заглавной страницы этого форума при том сервере, который стоит сейчас. Кроме того, оказалось, что версия из дистрибутива 0.7.7.0 отличается от версии, приложенной в предыдущем посте, возможностью сохранения результата в разделяемую область памяти вместо файла /rd/1/.download; эта версия содержит все изменения.

А SVN использовать сложно? Просто работу diamond'a по изготовлению ночных сборок это облегчило бы.
Вечером протестирую.

UPD. Результаты запостил в теме Снова qemu

Я увеличила ограничение на урл, доведя его до 256 символов. В качестве побочного эффекта теперь урл может не помещаться в поле для ввода. К сожалению, я не располагаю сейчас достаточным количеством времени для внесения достаточно существенных изменений по использованию библиотеки edit_box вместо примитивного ввода, унаследованного от httpc.
Mario, я закоммитила программу на svn, ревизия 1645. Я также прилагаю скомпилированную версию и исходные тексты здесь.

CleverMouse
Спасибо.
Если есть необходимость могу сам прикрутить box_lib - из минусов бинарник программы станет больше от 2 кб.
Также могу прикрутить OpenDialog, если есть в нем необходимость (для выбора рабочей директории например).

Mario, я думаю, что edit_box в downloader однозначно нужен, а OpenDialog ни к чему. Я, впрочем, думала, что реализации всех функций по управлению edit_box находятся в разделяемой библиотеке, а код программы должен содержать только загрузку этой библиотеки и вызовы функций, причём downloader уже загружает одну библиотеку libini. Неужели вызовы функций edit_box добавляют целых 2 Кб?

CleverMouse

Я, впрочем, думала, что реализации всех функций по управлению edit_box находятся в разделяемой библиотеке

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

Вызов Edit_Box добавит данные компонента, плюс три вызова процедур (отрисовка, клавиатура, мышь). Еще немного может добавить "обвязочный" код, если фокус ввода с клавиатуры потребуется устанавливать не только на Edit_Box. Ну, и остальное добавит макрос load_lib - я понимаю что есть другие способы загрузки и импорта библиотек, которые могут сократить размер кода загрузки библиотек, но они к сожалению не наглядны. Приложение просто вылетает при отсутствии библиотек или приходится создавать код объясняющий причину ошибки самому прикладному программисту, тогда как load_lib вполне себе сообщит в чем дело. Экономия этих 2 Кб не настолько существенна - профит для юзера от применения превосходит эту затрату. К тому-же в упакованном виде эти 2 Кб будут как минимум в 2 раза меньше, а возможно и еще больше сожмутся упаковщиком.

а OpenDialog ни к чему

Насколько я понимаю - загрузка не все время будет в рамдиск, а для пользователя редактировать INI файл достаточно муторное занятие.

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

Я взял на себя смелость оптимизировать код (никаких библиотек не прикручивал).

SVN r.1646
Downloader версии 0.5
1) Размер бинарника сократился более чем в два раза. В несжатом состоянии 4514 байт. Прежний код был почти 11 Кб.
2) Размер занимаемый в памяти сократился до 0x7000 (28 Кб), плюс то что выделится 68 функцией. Прежний код сразу запрашивал 0x100000 (1 Мб).
3) Окно при запуске с параметром теперь не рисуется - все события кроме сетевого запрещены.

У меня остался вопрос насчет области dnsMsg - я выделил 4 Кб, но не уверен что это достаточно. В прежнем коде область была ограничена тем самым 1 мб, за минусом стековой области. Если нужно больше 4 Кб то по идее можно выделять динамически, если знать нужный размер.