設計一個持久的非同步 TCP 協議
我有一個網站集合，需要向整個都會區的主機發送時間敏感消息，每個網站都有自己的一般動態 IP。到目前為止，我一直在按照腳本小子的方式這樣做：
- 每台主機執行一個（s）FTP伺服器或一個HTTP（s）伺服器，並相應地有一個由其網關打開的埠。
- 每台主機執行一個程序，該程序監視某個文件夾，並在出現給定副檔名的新文件時自動打開或列印或 exec()s。使用動態 DNS 服務提供動態 IP 地址。
- 每個網站都執行 cURL 或 fsockopen 或其他任何操作，並根據需要直接與其接收者通信。
這種方法非常可靠，但是出現了明顯的問題並且需要解決這種情況。
如前所述，這些消息具有時間敏感性，需要在最終使用者送出後的幾分鐘內檢測到故障。我正在做的是建構一個消息傳遞協議。它將在我控制的機器和連接上執行。就服務而言，網站和主機之間沒有區別——只有一個設備向另一台設備發送消息。
這就是我現在所處的位置。我有一個骨架伺服器和一個骨架客戶端。他們可以協商高質量的身份驗證和加密。(TCP) 連接是持久的和非同步的，並且可以處理分隔（即，讀取到*\r\n或其他）以及以長度為前綴（即，恰好讀取n*個字節）的消息。除非有人給我一個更好的主意，否則我認為我會將消息作為字節數組處理。
因此，我正在尋找有關如何在應用程序級別對協議本身進行建模的建議。我將主要傳輸 XML 和 DLM 類型的文件，以及諸如“握手”和“某某線上嗎？”之類的控制消息。等等。在我的構想中真的有什麼愚蠢的嗎？或者在我開始之前我應該閱讀什麼？像這樣的東西——請，謝謝。
更新：
@mrdenny’s 是我最終採用的方法，所以他得到了答案。@Henrik 的 ZeroMQ 建議也適用，但我基本上已經編寫好了程式碼，並且將我的程式碼切換為 3rd 方框架並沒有真正幫助設計應用程序層。最後，我發現 HTTP 是多麼的多才多藝，而且真的不需要自己動手的協議。除了他們已經在做的 text/html 之外，只需讓網站呈現內容類型 application/json（或 xml，如有必要），並讓接收者發出出站 Web 請求，而不是監聽和響應文件系統更新。消除了上述所有“腳本小子”成本，工作更可靠，實現更好的錯誤處理，易於建構等等。
有什麼理由不能只使用 Web 方法和 HTTP（或 HTTPS）呼叫在機器之間傳輸數據？
ZeroMQ被設計為非同步傳輸/消息協議。
如果您的一個節點出現故障，它將重新建立 ZMQ-Socket 並在到目標端點的路由恢復時繼續發送其消息。性能很好，根據其 IRC 頻道，它現在已經過充分測試，可以通過 WAN 使用。