我正在開發一個TCP服務器,如果指定的任務完成,它將與客戶端通信。所以我在服務器上打開一個套接字,客戶端連接上它。
該連接也可用於數據傳輸回客戶端。這很好。
但是,連接中止以及類似的事情呢?請求處理時永久TCP連接或連接建立
我的想法是每次連接到服務器,當客戶端必須與它通信。但是,我怎樣才能將數據發送回客戶端?
我也可以在客戶端打開一個套接字嗎?編輯:
我也考慮過WCF。我認爲這可能是實現服務器客戶端層次結構的一種非常好的方式。
你覺得呢?
我正在開發一個TCP服務器,如果指定的任務完成,它將與客戶端通信。所以我在服務器上打開一個套接字,客戶端連接上它。
該連接也可用於數據傳輸回客戶端。這很好。
但是,連接中止以及類似的事情呢?請求處理時永久TCP連接或連接建立
我的想法是每次連接到服務器,當客戶端必須與它通信。但是,我怎樣才能將數據發送回客戶端?
我也可以在客戶端打開一個套接字嗎?編輯:
我也考慮過WCF。我認爲這可能是實現服務器客戶端層次結構的一種非常好的方式。
你覺得呢?
這取決於您的其他要求。如果我們正在談論一個可能每天發送一次的消息,正確的解決方案可能是客戶端定期連接到服務器並檢查是否有消息。如果我們談論的是更常見,更急速的事情,那麼正確的解決方案可能是讓客戶始終保持與服務器的連接。在某些情況下,如果可能的話,正確的解決方案可能是讓服務器與客戶端建立「向後」連接 - 如果「向後」連接可能具有退回到從客戶端到服務器的持久連接的選項是不可能的。
請參閱Push technology上的這篇文章,特別是關於long polling的部分。
從服務器連接到客戶端的運行時間POV需要一個支持此(防火牆/ IDS等)的網絡環境。
如果你不能確定這種情況總是如此,那麼這個選項就排除了IMO。
至於客戶端保持連接打開:
我覺得這是一個不錯的選擇...您需要確保客戶端執行檢測到任何連接問題,並自動重新連接......
無論您實施什麼解決方案,您可能需要爲每個客戶端實施一系列事件...取決於您的請求,這些隊列甚至可能需要持久化......
WCF可以以我描述的所有方式工作,並提供幾件事情(如序列化,可選會話管理,傳輸安全等)這有助於構建一個強大且可維護的系統......儘管基於TCP/IP的純粹解決方案可能會更好地提高性能......
因爲存在事件,所以會有大量的事件客戶。 – CSchulz
我曾想過WCF。你怎麼看? – CSchulz