CADBiS начало...

Решил открыть серию постов посвящённых моему дипломному проекту. Проект представляет собой систему управления доступом в Интернет.
Акцент в проекте идёт не на расчёт стоимости потребляемых услуг и списание средств (или попросту говоря биллинг), а на специфику предприятия на котором данная система должна быть установлена, а именно - локальная сеть кафедры САПР, на которой я учусь.
Клиентами системы являются студенты, преподаватели, аспиранты и сотрудники. Каждая группа должна иметь собственные права и лимиты доступа. Так же необходимо создать систему управления контентом, который получают из Интернета пользователи, потому как по идее студенты должны расходовать Интернет-трафик исключительно в учебных целях, ровно как и преподаватели.
На сегодняшний день система успешно функционирует. Она основана на открытой биллинг-системе FreeNIBS, которая в свою очередь представляет собой модуль сервера аутентификации FreeRADIUS, являющегося на сегодняшний день одним из самых популярных RADIUS-серверов в сети. Установление соединений по протоколу pptp происходит с помощью сервера mpd. И крутится всё это дело на шлюзе под управлением FreeBSD.
Эта система была настроена, поставлена, к ней был разработан веб-интерфейс для администраторов. Код FreeNIBS был частично модифицирован и в него была добавлена функция работы с оповещениями пользователей. Так же был настроен и подключен прокси-сервер Squid, который позволил отфильтровать некоторые нежелательные веб-ресурсы. И всё это в рамках бакалаврского проекта.
В системе был лишь базовый функционал. Конечно, ни о каких фильтрах контента речи не было. Главным параметром являлся Интернет-трафик, и предполагалось что его верхний порог - вполне ограниченное число, а поэтому система должна была уметь распределить использование трафика как можно более рационально. Для этого в веб-интерфейсе была предусмотрена "система поддержки принятия решений", которая сообщала администратору о том, что в какой-либо из дней расход трафика превысил свою дневную норму. Что плохо? Система базировалась на FreeNIBS, а это как плюс так и минус. Минус в том, что код на языке C, отладить который можно лишь вкомпилив во FreeRADIUS, представляется абсолютно не-maintanable и не-extensible. На написание простейшей функции отправки уведомлений ушло несколько дней. Посему, данная часть была в последствии выделена в ядро и не модифицировалась по причине невероятной лени, возникающей при одной мысли об этом коде:)
Далее система расширялась при помощи написания собственного прозрачного proxy-сервера, который бы отслеживал посещаемые ресурсы, составлял протоколы и записывал в базу. Данный сервер был выбран без особых поисков - и им стал входивший в необновлённую версию портов FreeBSD 5.4 tproxy. Опять же пришлось писать ужасающий код на C. При этом, код был написан в лучших традициях классической UNIX-архитектуры и вместо использования POSIX-threads он реализовывал многозадачность при помощи fork (собственно, FreeRADIUS тоже её использовал, но нагрузка на него была в разы меньше). В результате чего сервер часто просто загибался от обилия процессов. К тому же запись логов в базу была реализована путём модифицирования кода tproxy и реализована в том же стиле, в результате чего на каждый пакет создавались процесс обработки запроса и процесс записи запроса в базу, и при этом (!) соединение с базой открывалось для каждого пакета!
Представить сейчас страшно, что я так мог написать. Естественно, что сервер умирал когда кто-то начинал что-то просто скачивать. Немного помогли шаманские пляски с sysctl (было увеличено максимальное число сокетов). Но в итоге от данной утилиты было решено отказаться.
Второй попыткой реализовать свой proxy было написание его с 0 на чистом C++. Здесь, разумеется всё было сделано уже умнее. Для многозадачности использовались потоки, для синхронизации - мьютексы, был реализован собственный потоковый пул (от POSIX-пула было решено отказаться по ряду причин) и всё работало прекрасно. Если бы не одно но. Память текла. А куда текла - было очень трудно понять. Учитывая моё неумение пользоваться средствами типа dbg и некоторую несовместимость кода с Windows-платформой, отладить момент утечки оказалось нереальным и эту ветку тоже пришлось заморозить.
Но вот пришло время когда до защиты магистерского диплома осталось всего пара месяцев. И неожиданно появилось желание реализовать proxy на Java, особенно после нескольких пробных попыток и оценки кроссплатформенности. И ведь действительно, данный проект оказался в итоге наиболее перспективным...

[To be continued]