Наконец-то дошли руки продолжить проект про серваки и сети. Постом выше описывал архитектуру как она есть в стадии концепта.

Сейчас дошел до того, что реализован первый протокол (сырой TCP, или более технично - "RawTCPProtocol). Тесты пишутся, первый запуск прошёл нормально.

Вот какие изменения произошли в архитектуре, на какие компромиссы пришлось пойти и что получилось по окончанию работ. Пройдусь снизу вверх, чтобы была более четкая параллель: 1. Mixin. Всего на каждый протокол - 4 миксина, а именно синхронный/асинхронный сервер/клиент. Тут ничего не изменилось, оставлю для напоминания о том, что уже готово. 2. Transport. На данный момент, все миксины с одинаковым типом использования (sync/async) объединяются в единый транспорт с явным делегированием через инициализацию супер-класса. Инициализируем миксины и сериализер. Главное изменение состоит в том, что ранее предполагалось создать "единый" транспорт, но из-за того что асинхронный и синхронный интерфейс легче разделить, чем прописывать все методы в едином классе было принято решение создать два транспорта. За такие плюсы, как чистота кода и разделение интерфейсов пришлось заплатить количеством написанного кода, что в будущем будет влиять на скорость написания новых базовых протоколов. Но данный недостаток с лихвой перекрывается чистотой кода и понятным разделением, а так же за счёт явной делегации нет нужды прописывать все методы делегируемого класса, что даёт больше гибкости. 3. Сериализер. Без изменений, все так же как и было - базовый класс + наследники с нужной реализацией композиции/декомпозиции пакетов (Полезно для надстроек по-типу модбаса и прочих, в которых используется TCP с другой сигнатурой пакетов) 4. Протокол. Самое интересное. Теперь протокол - место сборки транспорта с миксинами в единое целое. Главное изменение - отход от жёсткого прописывания всех методов делегируемого транспорта (универсальный шаблон базового протокола, на который потом вешаются наследники с нужным функционалом). Тут прекрасно подходит паттерн Фабрики, ведь по-сути сейчас протокол - фабрика транспортов, которая их собирает для общения и передает все нужные параметры, как единая точка доступа. Нет нужды писать несколько протоколов под TCP, а так же его можно использовать как базу (См. RawTCPProtocol) для надстроек над TCP, в том числе - кастомных, от юзеров (Подробнее - ниже). Снижение количества кода позволит быстро писать протоколы под уже существующий транспорт, но для этого потребовалось вынести логику в базовый класс, что снижает гибкость в перспективе (На данный момент, под текущие задачи гибкости вполне хватает, можно делать надстройки и писать свои протоколы по шаблону за минуту). 5. Device. Точка доступа для пользователей, которая администрирует весь жизненный цикл протокола, который вызван пользователем. Тут ничего не изменилось - два универсальных контекстных менеджера, которые принимают протокол и запускают его в нужном контексте (sync/async), а так же мониторинг + логирование всех действий. На этом подходит к концу описание логики работы с железом и ее администрирования. Перейдем к новой теме - открытое API, которое будет давать возможность юзеру получать доступ к основным core-методам для написания своих протоколов, а так же к фабрике для дальнейшей регистрации этих самых протоколов. Пока что структура планируется следующая: 1. manager. Консольный менеджер для вызова команд через cmd (По своей сути - CLI приложение для работы с API) 2. API. Структура для предоставления доступа к конкретным реализациям, которые предусмотрены как открытые для юзера. Позволит импортировать базовые классы и реализации доступных протоколов и их надстроек. 3. factory. Класс фабрики для регистрации самописных протоколов, чтобы они были совместимы с Device. Нужен для типизации, но так же планируется сделать ограничение на импорты базовых классов и предоставление доступа только к высокоуровневым интерфейсам.

На данный момент API - концепт, прошу строго не судить и буду очень рад выслушать идеи, конструктивную критику для улучшения кода.

Всем большое спасибо за внимание!