我收集了一些网站，这些网站需要将时间敏感的消息发送到我都市区的主机，每个主机都有自己的一般动态 IP。直到现在，我一直在按照脚本小子的方式这样做：
每台主机运行一个(s)FTP服务器，或者一个HTTP(s)服务器，并相应地有一个由其网关开放的特定端口。
每台主机都运行一个程序，该程序监视某个文件夹并在出现给定扩展名的新文件时自动打开或打印或执行（）。使用动态 DNS 服务提供动态 IP 地址。
每个网站都执行 cURL 或 fsockopen 或其他任何操作，并根据需要直接与其接收者通信。
这种方法非常可靠，但是出现了明显的问题并且需要解决这种情况。
如前所述，这些消息对时间很敏感，需要在最终用户提交后的几分钟内检测到故障。我正在做的是构建一个消息传递协议。它将在我控制的机器和连接上运行。就服务而言，网站和主机之间没有区别——只有一个设备向另一个设备发送消息。
这就是我现在所处的位置。我有一个骨架服务器和一个骨架客户端。他们可以协商高质量的身份验证和加密。(TCP) 连接是持久的和异步的，并且可以处理定界（即，读到\r\n或其他）以及长度前缀（即，恰好读取n字节）的消息。除非有人给我更好的主意，否则我想我会将消息作为字节数组处理。
所以我正在寻找有关如何在应用程序级别对协议本身进行建模的建议。我将主要传输 XML 和 DLM 类型的文件，以及诸如“握手”和“某某人在线吗？”之类的控制消息。等等。我的思路真的有什么愚蠢的地方吗？或者我在开始之前应该阅读的任何内容？诸如此类的事情——请和谢谢。
更新：
@mrdenny's 是我最终采用的方法，所以他得到了答案。@Henrik 的 ZeroMQ 建议也适用，但我基本上已经编写了代码并且将我的代码切换为第 3 方框架并没有真正帮助设计应用程序层。最后，我发现了 HTTP 的用途是多么的多，而且真的不需要自己开发协议。除了它们已经在做的 text/html 之外，只需让网站呈现内容类型 application/json（或 xml，如果需要），并让收件人发出出站 Web 请求，而不是监听和响应文件系统更新。消除了上面描述的所有“脚本小子”开销，工作更可靠，实现更好的错误处理，易于构建等等。