У меня есть коллекция веб-сайтов, которым необходимо отправлять чувствительные ко времени сообщения на хост-машины по всему моему городу, каждый из которых имеет свой собственный обычно динамический IP. До сих пор я делал это как сценарий kiddie:
Каждая хост-машина запускает FTP-сервер или HTTP-сервер и, соответственно, имеет определенный порт, открытый своим шлюзом.
Каждый хост-компьютер запускает программу, которая следит за определенной папкой и автоматически открывает, печатает или выполняет функции exec (), когда появляется новый файл с заданным расширением. Динамические IP-адреса размещаются с помощью службы динамического DNS.
Каждый веб-сайт использует cURL или fsockopen или что-то еще и при необходимости напрямую связывается со своим получателем.
Этот подход оказался на удивление надежным, однако возникли очевидные проблемы, и ситуацию необходимо решить.
Как уже говорилось, эти сообщения чувствительны ко времени, и сбои должны обнаруживаться в течение нескольких минут после отправки конечными пользователями. Я занимаюсь построением протокола обмена сообщениями. Он будет работать на машине, и соединение под моим контролем. Что касается сервиса, то здесь нет различия между веб-сайтом и хост-машиной - есть только одно устройство, отправляющее сообщение другому устройству.
Вот где я сейчас нахожусь. У меня есть скелетный сервер и скелетный клиент. Они могут согласовывать высококачественную аутентификацию и шифрование. Соединение (TCP) является постоянным и асинхронным и может обрабатывать с разделителями (т. Е. Читать до тех пор, пока \ г \ п или что-то еще), а также с префиксом длины (т.е. читать точно п байтов) сообщения. Если кто-то не подскажет, я буду обрабатывать сообщения как байтовые массивы.
Поэтому я ищу предложения по моделированию самого протокола - на уровне приложения. В основном я буду передавать файлы типов XML и DLM, а также управляющие сообщения для таких вещей, как «рукопожатие» и «такой-то онлайн?» и так далее. Есть ли что-нибудь действительно глупое в моих мыслях? Или что-нибудь, о чем я должен прочитать перед тем, как начать? Такие вещи - пожалуйста и спасибо.
Обновить:
@ mrdenny - это подход, которого я в конечном итоге придерживаюсь, поэтому он получает ответ. Предложение @Henrik ZeroMQ также применимо, но у меня в основном это уже было, и переключение моего кода на сторонний фреймворк на самом деле не помогло разработать уровень приложения. В конце концов, я обнаружил, насколько невероятно универсальным может быть HTTP, и в самом деле нет необходимости в протоколе для самостоятельной работы. Просто позвольте веб-сайтам представлять тип содержимого application / json (или xml, если необходимо) в дополнение к тексту / html, который они уже делали, и позвольте получателям делать исходящие веб-запросы вместо того, чтобы слушать и отвечать на обновления файловой системы. Устраняет все описанные выше накладные расходы на "script kiddie", работает намного более надежно, обеспечивает более эффективную обработку ошибок, простоту сборки и многое другое.
ZeroMQ был разработан как асинхронный транспортный протокол / протокол сообщений.
Если один из ваших узлов выйдет из строя, он восстановит ZMQ-Socket и продолжит отправку своих сообщений, когда маршрут к целевой конечной точке восстановится. Производительность хорошая, и, судя по его каналу IRC, в настоящее время он достаточно хорошо протестирован для использования через WAN.
Есть ли причина, по которой вы не можете просто использовать веб-методы и HTTP (или HTTPS) вызовы для передачи данных между машинами?
Посмотрите FIX (например, FIX Protocol), чтобы увидеть, как может выглядеть такой протокол. Вы МОЖЕТЕ просто использовать FIX и библиотеку с открытым исходным кодом и сами делать все определения полей. FIX используется для финансовой торговли.
Но это должно дать вам хорошее представление. FIX также может / обрабатывает такие элементы, как сохранение сообщений в случае разрыва соединения, если это необходимо.