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

Question

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

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

Кажется, есть много информации о дизайне программного обеспечения, но не о дизайне протокола. Я уже посмотрел Дизайн протокола приложения .

Answer 1

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

Answer 2

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

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

Answer 3

Еще одна рекомендация для буферов протокола - хороший компактный двоичный файл без особых усилий. Однако обратите внимание, что хотя двоичный протокол четко определен, еще не существует согласованного стандарта RPC ( некоторые находятся в процессе , склоняясь к TCP или HTTP).

Спецификация позволяет очень легко иметь клиент и сервер в разных архитектурах что хорошо - плюс расширяемо.

Предупреждение: я являюсь автором одной из версий .NET так что я вполне могу быть предвзятым ;-p

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

  

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

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