Разработка постоянного асинхронного протокола TCP

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

1. На каждом хост-компьютере работает FTP-сервер (-ы) или HTTP-сервер (-ы), и, соответственно, определенный порт открыт для его шлюза.

2. На каждом хост-компьютере запускается программа, которая просматривает определенную папку и автоматически открывает или печатает или выполняет exec() при появлении нового файла с заданным расширением. Динамические IP-адреса размещаются с использованием службы динамического DNS.

3. Каждый веб-сайт делает cURL или fsockopen или что-то еще и общается напрямую с получателем по мере необходимости.

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

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

Так вот где я сейчас. У меня есть скелетный сервер и скелетный клиент. Они могут договориться о высококачественной аутентификации и шифровании. Соединение (TCP) является постоянным и асинхронным и может обрабатывать сообщения с разделителями (т. Е. Читать до \r\n или что-либо еще), а также сообщения с префиксом длины (т. Е. Читать ровно n байтов). Если кто-то не даст мне лучшей идеи, я думаю, что буду обрабатывать сообщения как байтовые массивы.

Поэтому я ищу предложения о том, как смоделировать сам протокол - на уровне приложения. В основном я буду передавать файлы типа XML и DLM, а также контрольные сообщения для таких вещей, как "рукопожатие" и "такой-то онлайн"? и так далее. Есть ли что-то действительно глупое в моем ходу мыслей? Или что-нибудь, о чем я должен прочитать, прежде чем начать? Вещи, как это - пожалуйста, и спасибо.

Обновить:

@ mrdenny's - подход, с которым я в конечном итоге ушел, поэтому он получает ответ. Предложение Henrik's ZeroMQ также применимо, но у меня уже была эта кодировка, и переключение моего кода на стороннюю платформу не очень помогло в разработке уровня приложений. В конце концов, я обнаружил, насколько невероятно универсален может быть HTTP, и в действительности нет необходимости в протоколе "сам по себе". Просто дайте веб-сайтам представить тип контента application/json (или xml, если необходимо) в дополнение к тексту / html, который они уже делали, и пусть получатели отправляют исходящие веб-запросы вместо прослушивания и ответа на обновления файловой системы. Устраняет все описанные выше издержки "script kiddie", работает намного надежнее, обеспечивает намного лучшую обработку ошибок, простоту сборки и многое другое.