Kiddie labor

[kika]

http://kika.livejournal.com/32433.html?thread=188849#t188849

Вопрос простой - а где у нас в ЗАО РФ нынче учат на программистов? В смысле учат, а не "учат", то есть не читают лекции про эльбарроуз, а откуда выходят неплохие хакеры, способные аргументированно обсуждать стиль написания ядра Линукса и BSD. Ну или еще что-либо такое же высокодуховное и бесполезное.

Comments

[pzz.livejournal.com]

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

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

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

[rblaze.livejournal.com]

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

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

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

[pzz.livejournal.com]

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

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

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

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

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

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

[rblaze.livejournal.com]

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

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

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

[pzz.livejournal.com]

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

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