請問用tcp協議實現sever push技術的思路？

01-08

了解了一些sever push技術，比如comet，flash xml socket都是web程序的解決方案，現在想實現一套基於tcp協議的非web程序伺服器推送技術，我們用準備用tcp長連接做推送應該著重注意什麼？
(註：用TCP長連接是最基本的，由於我們的客戶端基數達到10萬級，我想詳細了解下在用tcp長連接做推送有什麼需要注意的地方？比如說資源影響和效率影響）

直接TCP長連接唄。

實操過幾個複雜的大批量推送系統

最好用80、443這些常見埠，防止被運營商無良封鎖，這樣會帶來一個問題，可能會被運營商的Cache（Squid、Varnish之類）劫持。
為了解決上面的問題，需要有一個心跳包和伺服器交互探活。
這個連接只用來做通知，較大數據通過別的方式傳輸。

暫時想到的就這些，想到了再補充

XMPP 可以用來處理這類的問題。包括 facebook chat，Apple push，RabbitMQ，都是基於XMPP協議來做的。

優點是伺服器成熟，有支持最好的 Ejabberd，也有易於開發使用的 Openfire；核心協議已經支持了幾乎所有的需求；擴展能力強，實現新功能很容易。而且對於傳輸層丟數據的問題，XMPP 也有專門的應用層確認機制，能保證數據到達。

缺點是基於 XML，導致冗餘數據大，即使壓縮之後也是，交互較多，不太適合在移動設備上使用。

需要 Ejabberd 支持可以聯繫我啊，Erlang 原生的分散式系統，對於並發的 XMPP 伺服器來說，是再合適不過的了，完全可以做到線性水平擴展。

喜歡lz這個問題，看似簡單，其實做起來會有很多細節要注意，如果能問到一些經驗，能少走彎路

單純做push服務的話，個人趕腳沒必要用xmpp協議，那東西太冗餘太沉重了，而且文本文檔協議肯定比binary的二進位協議傳輸要大。需要注意的是：長連接的保持，下發效率，和客戶端心跳的保活（sdk的喚起）等這幾點都是比較重要的。

tcp server push其實就是長連接。

試試 TCP 介面服務框架 - C# 高性能自動化服務端框架 - 凹凸架構，簡單易用。

首先TCP 是傳輸層協議，任何推送系統都是基於TCP 的。
要實現實時推送就要在客戶端建立一條和服務端的長連接。xmpp可以很容易實現。我做了1年多的ejabbed二次開發，一台8g4核的伺服器，使用ejabberd，連接可以達到30W。使用集群，然後再提高單機配置，維持千萬級別的連接也不是問題。whatapp使用ejabberd已經做到了單機連接300W。
至於其他答案說的由於網路的不穩定，以及中間路由崩潰導致的連接中斷，如果你的客戶端主要是手持設備，確實存在這個問題，xmpp協議是比較臃腫的。但是ejabberd支持應用層的保活心跳包，只需要你配置一下即可。