У меня есть существующее автономное приложение, которое будет распространяться сторонним, используя сетевой протокол. Возможности уже реализованы, все, что мне нужно, это разоблачить их снаружи.
Предполагая, что транспортный протокол уже выбран (UDP), есть ли какие-либо ресурсы, которые помогут мне разработать протокол приложений?
Кажется, что много информации о разработке программного обеспечения, но не о дизайне протокола. Я уже рассмотрел Application Protocol Design.
См. Руководства по разработке протоколов Jabber и RFC 4101. Несмотря на то, что он нацелен на то, чтобы сделать RFC более понятным для рецензентов, этот RFC содержит несколько интересных советов.
Прежде всего, UDP - это, в первую очередь, односторонний широковещательный транспортный метод. Кроме того, это потенциально lossy, поэтому вам нужно иметь возможность обрабатывать отсутствующие пакеты и пакеты вне порядка. Если вам нужен какой-либо уровень надежности от UDP или требуется двухстороннее соединение, в конечном итоге вам потребуется всего около всего от TCP, поэтому вы можете пойти с этим, чтобы начать с этого, и пусть сетевой стек позаботится об этом.
Далее, если ваши данные потенциально больше одного IP-пакета, вам понадобится какой-то способ определения начала и конца каждого пакета и средство обработки незаконных или поврежденных пакетов. Я бы рекомендовал какой-то заголовок с длиной пакета, какой-то нижний колонтитул и, возможно, контрольную сумму.
Затем вам нужно каким-то образом кодировать сообщения и ответы. Существует много протоколов RPC. Вы можете посмотреть SOAP или создать собственный XML-протокол или двоичный файл.
Вы посмотрели Google Protocol Buffer? Кажется, это хороший способ решить эту проблему.
Вы можете создать конечную точку, которая обменивается данными с вашим существующим приложением, а затем отвечает извне, используя протокол protobuffer. Он двоичный, поэтому он крошечный и быстрый, и вам не нужно писать собственный диспетчер протоколов, потому что вы можете использовать Google. Недостатком является то, что он должен быть реализован по обе стороны системы (на стороне вашего сервера и на стороне потребителя/клиента).
Еще одна рекомендация для буферов протоколов - неплохая жесткая бинарная система с небольшими усилиями. Обратите внимание, однако, что, хотя бинарный протокол хорошо определен, еще не согласован стандарт RPC (несколько из них продолжаются, стремясь наклоняться к TCP или HTTP).
Спецификация упрощает работу с клиентом и сервером в разных архитектурах, что является хорошим - плюс расширяемость.
Предостережение: я являюсь автором одной из .NET версий, поэтому я вполне могу быть предвзятым; -p
Вы действительно должны серьезно подумать о том, хотите ли вы действительно разрабатывать, документировать и поддерживать собственный протокол или использовать то, что уже существует. Вероятно, уже есть документированный протокол, который соответствует вашим потребностям. В зависимости от того, что вы делаете, это, вероятно, сначала будет излишним, и реализация всех спецификаций будет выглядеть утомительно и намного менее забавно, чем писать ваши собственные, но если вы намерены продолжать разработку своего приложения через несколько лет, это должно сэкономить вам много времени и денег, чтобы использовать то, что уже существует и известно третьими лицами. Кроме того, если вы можете использовать существующую библиотеку для этого протокола, часть реализации должна быть намного быстрее.
Разработка нового протокола более увлекательна, чем реализация одного, но меньше, чем его поддержание, поскольку вы должны жить со всеми недостатками. Ни один протокол не является совершенным, но если вы его никогда не разрабатывали, вы можете быть уверены, что будете ошибаться в его разработке, чем люди, которые разработали существующий известный протокол, который вы могли бы использовать вместо этого.
Короче говоря, используйте то, что уже существует, когда это возможно.
Если вы не хотите создавать свой протокол с нуля, вы должны взглянуть на SOAP. Поддержка различна для разных языков программирования, но явно поддерживается обмен языками на разных языках.
К сожалению, UDP и SOAP, похоже, застряли в зачаточном состоянии, чаще всего используется HTTP.
Если вы выбираете XML, имейте в виду, что у вас будет огромная нагрузка на разметку.
Для простого бинарного протокола также потребуется не столько ressources для синтаксического анализа по сравнению с xml.
У меня есть существующее автономное приложение, которое будет распространяться сторонним, используя сетевой протокол.
Это поможет узнать немного больше о том, что делает ваша программа, и о том, что характер этих сторонних расширений. Может быть, какое-то обоснование для использования UDP?