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

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

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

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

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

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

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

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

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

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

I have an existing standalone application which is going to be extended by a 3rd-party, using a network protocol.

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

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

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

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

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

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

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

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