Проектик: питон, asyncio, socket и прочие приблуды
Недавно начал писать свой проект. Хочу довести его до пристойного уровня. Мои шаги - чистая, масштабируемая и понятная архитектура, четкое разделение зависимостей, грамотная реализация. Возможно, то что напишу ниже - поможет новичкам вкатиться в сетевые технологии, или просто будет кому-то полезным.
На данный момент архитектура приложения выглядит следующим образом:
Mixin-классы, которые описывают поведение определенного функционала, к примеру - BaseSyncConnectable, или BaseAsyncSendRecv. Служат соответственно для создания подключения и отправки/принятия данных (Работа непосредственно по взаимодействию с сетевым устройством/устройствами).
Соглашения по использованию миксинов, или же интерфейсы для написания конкретных реализаций. Являются базовыми абстракциями, которые объединяют в себе определенные миксины в зависимости от мода (sync/async) и типа протокола (например, TCP требует методов connect/accept, которые реализованы в BaseConnectable, а udp обходится простыми send/recv).
Сериализаторы. Структуры, которые приводят пакеты, которые передаются в сети, к определенному единому стандарту для облегчения написания стандартных парсеров. Пример использования - отсечение заголовков MosbusTCP, которые несут скорее техническую, чем пользовательскую информацию (Номер транзакции, функции modbus, прочая техническая история). В "голом" TCP просто кидаются байты.
Структура типа Транспорт. Является объединением сериализатора и миксина. Объедниение происходит путем делегирования, так как нужно заменять сериализатор и миксин в зависимости от требуемого протокола (см. ниже). По-сути, транспорт - это то, как общаются устройства (В соответствии с одноименным 4 уровнем модели OSI)
Протокол. В протокол мы делегируем транспорт и парсеры, и с помощью декораторов (АОП) добавляем функционал/регистрацию протокола по его моду, имени, прочим параметрам уникальным для конкретного протокола (Всегда единое количество параметров).
Немножко объяснения. Пойдем сверху вниз:
Протокол - средство для предоставления пользователю инструмента по использованию сети (Транспорт) в удобном для него формате, с возвратом читабельных данных (Парсер).
Транспорт - средство общения машин на уровне сети, с приведением к единому виду данных в виде байтовой строки
Сериализер - средство для непосредственного приведения данных к единому стандарту.
Миксин - конкретная реализация через нужные средства разработки.
Таким образом получаем масштабируемую, удобную для изменения архитектуру, которая так же планируется выпускаться в виде SDK и API для сторонних пользователей.
Но как использовать данный инструмент для работы с сетями? Для этого предусмотрена система с использованием паттерна фабрики (Factory) и паттерна Устройство (Device):
Factory - класс, который регистрирует и делегирует нужные протоколы с нужными параметрами.
Device - контекстный менеджер для использования приведенных к единому виду протоколов. Он администрирует работу протокола с помощью threading, logging и прочих библиотек "надзора" за сетью для предоставления данных о работе приложения (Debug mode). Так же позволяет юзеру быстро интегрировать нужные протоколы по их названию и параметрам запуска.
Подобный подход обеспечивает четкое разделение зависимостей, где каждый элемент отвечает только за одно - реализацию, сериализацию, парсинг, регистрирование, делегирование и администрирование.
Надеюсь, пост был информативен для новичков, интересен для титанов IT, и просто помогал скрасить тяжкие дни рабочего офиса во время перерыва. Так же буду признателен за конструктивную критику.
Всем спасибо за уделённое время!
· 17.09.2025
Даже самый длинный путь начинается с первого шага! Удачи на твоем пути.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён