HTTP服務器是IPC的好主意嗎？

我需要實現一個工具，它可以從POST/GET機制中獲取正在運行的進程的數據。客戶端/服務器之間的連接數量非常低 - 平均每分鐘一個請求。HTTP服務器是IPC的好主意嗎？

默認的方法是基於套接字等實現一個簡單的服務器。但是，我覺得這麼簡單的工作太多了。有很多工具可以創建只有5行代碼的HTTP服務器（例如Perl Dancer）。與它們連接起來既快速又簡單。添加新功能非常簡單。資源方面，它們非常輕便。

對於這樣的任務HTTP（HTTP）服務器是一個壞主意嗎？是否有一個類似於Daner/node.js的IPC簡單RESTful框架？

謝謝！

2014-01-09 Mattan

如果你不關心網絡延遲，那就去吧。 –

HTTP基本上是一種無狀態協議。你請求一些東西，服務器回覆，這就結束了。 HTTP 1.1已經改變了部分實現，主要是出於性能原因，但它並沒有真正改變「客戶端發送 - 服務器答案 - 事務完成」模式。這意味着如果你想實現服務器啓動的鎖定機制，同步或者事務，你必須做很多的編碼才能使HTTP完成它沒有設計的功能。

這並不意味着沒有辦法做這些事情，它只是意味着您可能需要做大量的編碼才能使HTTP服務器執行您所需要的操作。從長遠來看，根據您的特定需求構建服務器會比試圖濫用HTTP服務器更容易。

當然，如果HTTP能夠做的事足以滿足您當前的需求，並且如果您處於快速編碼比性能和長期可維護性更重要的環境中，請使用HTTP服務器。如果你能在一天內完成這項工作，並且事先知道需求不會有太大變化，那麼花費十天的時間才能獲得性能提高3％，可維護性提高2％的解決方案並沒有什麼意義。

來源

2014-01-09 15:10:45

TCP基本上是無狀態協議。這意味着如果你想實現服務器啓動的鎖定機制，同步或事務處理，就必須進行大量的編碼，才能使TCP完成它未設計的任務。猜猜他不應該使用TCP。那個知識產權更糟糕！不惜一切代價避免！ – ikegami

TCP不是無狀態協議。如果你不相信我，請參閱http://en.wikipedia.org/wiki/Stateless_protocol#Stacking_of_stateless_and_stateful_protocol_layers。 –

它沒有請求的概念，那麼它如何維持請求之間的狀態呢？關鍵是你在吹捧東西，尤其是當OP提到HTTP是Dancer下面的一層時，它肯定會支持會話。 – ikegami

HTTP服務器是IPC的好主意嗎？

回答

相關問題