kika

И еще одна.

Есть програмка fuse (http://fuse.sourceforge.net/), позволяющая реализовать файловую систему в user space.

Предлагается написать аналог для реализации в user space сетевого протокола (т.е., address family).

Назвать можно suse :-) (от слова socket).

From:

Ну вообще-то bpf и sysvipc уже написаны, этого достаточно для user-space протоколов, если не морочиться безопасностью.

From:

Я имею ввиду именно address family. Т.е., возможность создать свои тип сокетов, существующий параллельно с AF_INET, AF_UNIX, AF_INET6, ...

В винде аналогичные вещи делаются с помощью layered service provider: http://en.wikipedia.org/wiki/Layered_Service_Provider

Но конечно, хотелось бы получить не столь замороченную конструкцию.

From:

Пишем shared library, перекрывающую работу с сокетами. Для "системных" AF она дергает стандартный API, для "своих" работает самостоятельно.

Прием-передача пакетов -- через bpf, разделение ресурсов (аналог портов TCP/UDP) через shared memory.

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

From:

Ты не путай, пожалуйста, 2 вещи:
1. Перекрытие сокетного API
2. Собственно реализация протокола

Давай для начала ограничимся IP-based (или даже UDP-based) протоколами. Тогда возню с BDF'ом можно отложить на потом. Да и вообще, как послать/принять сырой пакет более-менее понятно.

Что касается перекрытия сокетного API, да, конечно, это можно сделать, подсунув библиотеку, перекрывающую socket(), close(), send(), recv(), read(), write(), ...

Некоторые так и делают

Однако есть определенные сложности:
1. В такой архитектуре очень сложно сделать select(), позволяющий смешивать наши сокеты с настоящими. Микрософту это не удалось :-)
2. Ненастоящесть наших сокетов будет вылезать из других интересных мест. Например, если я запускаю из себя процесс, перенаправив его ввод/вывод в такой сокет, но в этот процесс наша библиотека не загружена, то это работать не будет. То же самое, если я передам такой сокет другому процессу через sendmsg()

Ну и в конце концов, псевдотерминалы и файловые системы тоже можно было бы сделать в shared library. Но однако так не делают, потому что аккуратно это сделать сложно и неудобно.

From:

Ну тут цели разные, видимо. Если для упрощения разработки протоколов делать, то надо лезть в ядро, регистрировать там нужные AF и выводить все callback'и наружу через /dev какой-нибудь. Возникнут интересные вопросы про асинхронность вызовов и т.п., но всё это в принципе решается.

Я-то на другое ориентировался: снижение общих накладных расходов на endnode, честная дележка между процессами и другие серверно-важные вещи. Тут можно вынести вообще все протоколы из ядра, оставить лишь продвинутый BPF и выделение уникальных ресурсов. Последнее можно и в shared memory держать, но в ядре будет безопаснее.

Не сам придумал, конечно, отсюда большую часть стянул: http://pdos.csail.mit.edu/~engler/dpf.html

From:

Интересные вопросы, это как раз хорошо. Это увеличивает ценность задачи как задачи для студентов.

Про DPF. Забавно, что winpcap реализует BPF именно как описано в статье, создавая маленькую ассемблерную програмку прямо в памяти.

From:

У netfilter есть же модуль такой, queue или что-то типа того, который ворует пакеты из цепи и отдает их в user space, а потом из user space получает и обратно вбрасывает

Но я точно не знаю что он может, я его смотрел только на предмет изучения внутренностей netfilter

From:

.. а в user space мы энкапсулируем либо в UDP либо в TCP, смотря что за протокол у нас, и забрасываем обратно. Теперь мы его можем использовать из обычного сокета - recvmsg и вот наш пакетик или read и получаем наш стрим

From:

Сокет это вовсе не обязательно что-то, что генерирует в конечном итоге UDP или TCP пакеты.

Переформулирую задачу другими словами. Я хочу иметь возможность создать вызовом socket() объект, который выглядит как нормальный сокет. Т.е. позволяет делать над собой все те же операции, которые позволяет делать обычный сокет. В частности, может быть использован вместе с другими файловыми хендлами в select'е (poll'е), может быть передан как файловый хендл другому процессу, и позволяет использовать protocol-specific опции в setsockopt/getsockopt, и auxiliary data в sendmsg/recvmsg.

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

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

From:

Сокет это что-то, что в конечном счете передает либо пакеты либо поток байтов между двумя эндпойнтами. Эмулировать настоящий сокет на линаксе трудно, а может даже и невозможно. Поэтому я предлагаю ничего не эмулировать, а отдавать программе нормальный UDP, скажем, сокет, через который она может принимать и посылать пакеты, ждать его в poll и все такое. Вот только общаться она будет через враппер, который будет протокольные адреса преобразовывать в фэйковые IP, а потом эти фэйковые IP говорить другому куску вареза. Этот кусок подучит ipt_QUEUE или как там его нынче зовут доставать пакеты этого протокола и UDP с и на эти фэйковые адреса, отдавать и то и другое в юзер спэйс, где имплементация протокола будет его процессить и энкапсулировать (или декапсулировать и процессить)

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

From:

А зачем UDP? Уровень сокетов во всех ядрах инкапсулирован достаточно хорошо, туда несложно добавить свои записи для любых AF и отдавать их программе совершенно честно.
Другой вопрос, что в BSD, например, эти таблицы статические, но это не непреодолимое препятствие, всё можно изменить.

From: