Пользовательский протокол Python Twisted: хорошие практики и сложность?

Question

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

Вот как это происходит в настоящее время: (извините заранее, может быть немного долго)

1. для работы с различными типами устройств (каждое из которых имеет свою прошивку и протокол связи). Я разработал систему «драйвера»:
   • каждый драйвер состоит из:
     • «класс аппаратного обработчика»: оболочка класса serial Twsited с несколькими добавленными вспомогательными методами
     • пользовательский последовательный протокол

2- При реализации драйверов для принтеров Reprap 3d (также основанных на Arduino, также использующих последовательное соединение) с довольно специфическими протоколами (например, enqueue point, set температура и т. Д.), Я начал задаваться вопросом, помещаю ли я методы для обработки этих функций (каждая из которых имеет определенные команды) в нужном месте ..

Это все приводит меня к моим вопросам:

Я не совсем уверен в хороших методах использования витых протоколов, но, просмотрев документацию / код довольно многих из них, кажется, что у них относительно мало методов

• всегда ли это так?должен ли протокол only использоваться для функций очень низкого уровня, а также для форматирования и обмена данными ввода / вывода?
• определенные устройства, которыми я хочу управлять, имеют очень четко определенные протоколы (Makerbot и т. Д.). Должен ли я считать, что общие спецификации протокола отличаются от реальных классов Twisted, которые я создаю?

Любые советы, советы и указатели приветствуются!Заранее спасибо.

Answer 1

Я постараюсь ответить на, в общем, довольно общий вопрос.

1) Интерфейс, составляющий протокол Twisted, имеет только 4 метода: http://twistedmatrix.com/documents/11.0.0/api/twisted.internet.interfaces.IProtocol.html Так что это будетгде происходит все взаимодействие между вашими реализациями протокола и Twisted.

2) Помимо экземпляров протокола, существует, конечно, фабрика, которая создает экземпляры вашего протокола (для каждого нового соединения).Так, например, вещи, которые должны быть доступны всем соединениям (например, текущее количество подключенных клиентов, что угодно), естественно, находятся там.

3) Конечно, может иметь смысл создавать небольшие иерархии классов, где вы получаетеиз протокола реализуйте содержимое, которое используется всеми вашими подпротоколами, а затем снова реализуйте только спецификацию подпротокола в производном классе.