Разработка протокола приложения

Question

У меня есть существующее автономное приложение, которое будет распространяться сторонним разработчиком с использованием сетевого протокола. Возможности уже реализованы, мне нужно только разоблачить их снаружи.

Предполагая, что транспортный протокол уже выбран (UDP), есть ли какие-либо ресурсы, которые помогут мне разработать протокол моего приложения?

Существует, по-видимому, много информации о разработке программного обеспечения, но не о конструкции протокола. Я уже посмотрел Application Protocol Design.

Answer 1

См Jabber protocols design guidelines и RFC 4101. Несмотря на то, что он нацелен на то, чтобы сделать RFC более понятным для рецензентов, этот RFC содержит несколько интересных советов.

Answer 2

Во-первых, UDP - это, в первую очередь, метод одностороннего широковещательного транспорта. Кроме того, это потенциально с потерями, поэтому вам нужно иметь возможность обрабатывать отсутствующие пакеты и пакеты не по порядку. Если вам нужен какой-либо уровень надежности от UDP или требуется двухстороннее соединение, в конечном итоге вам потребуется всего около всего от TCP, поэтому вы можете пойти с этим, чтобы начать с этого, и пусть сетевой стек позаботится об этом.

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

Затем вам нужно каким-то образом кодировать сообщения и ответы. Существует много протоколов RPC. Вы можете посмотреть SOAP или создать собственный XML-протокол или двоичный.

Answer 3

Если вы не хотите строить свой протокол с нуля, вы должны взглянуть на SOAP. Поддержка различна для разных языков программирования, но взаимное языковое общение явно поощряется.

К сожалению, UDP и SOAP, похоже, застряли в зачаточном состоянии, чаще всего используется HTTP.

Answer 4

Если вы выберете XML, имейте в виду, что у вас будет гигантский накладной разметки.

Простым бинарным протоколом также потребуется не так много ресурсов для разбора по сравнению с xml.

Answer 5

Вы посмотрели Google Protocol Buffer? Кажется, это хороший способ решить эту проблему.

Вы можете создать конечную точку, которая связывается с вашим существующим приложением, а затем отвечает извне, используя протокол protobuffer. Он двоичный, поэтому он крошечный и быстрый, и вам не нужно писать собственный диспетчер протоколов, потому что вы можете использовать Google. Недостатком является то, что он должен быть реализован по обе стороны системы (на стороне вашего сервера и на стороне потребителя/клиента).

Answer 6

У меня есть существующее автономное приложение, которое будет распространяться сторонним производителем, используя сетевой протокол.

Это поможет узнать немного больше о том, что делает ваша программа, и о том, что характер этих сторонних расширений. Может быть, какое-то обоснование для использования UDP?

Answer 7

Другая рекомендация для protocol buffers - хорошая жесткая бинарная система с небольшим усилием. Обратите внимание, однако, что, хотя бинарный протокол хорошо определен, еще нет согласованного стандарта RPC (several are in progress, который склоняется к TCP или HTTP).

Спецификация очень проста в том, что клиент и сервер в different architectures, что хорошо - плюс расширяемость.

Оговорка: Я автор одного из .NET versions, так что я вполне могу быть смещен ;-p

Answer 8

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

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

Короче говоря, используйте то, что уже существует, когда это возможно.