IM(Instant Messaging)即時通訊系統(tǒng)，從1996年ICQ的出現(xiàn)，到國際巨頭割據(jù)的今天，已經(jīng)深刻地影響了互聯(lián)網(wǎng)，甚至人類社會的變化。從移動互聯(lián)網(wǎng)時代開始，即時通訊系統(tǒng)更是加劇演變進化，除了iOS和Android提供全世界范圍的Push Notification Service，還形成了各種開放的云推送平臺與服務，成為巨頭廝殺圈地的戰(zhàn)場。在可預見的物聯(lián)網(wǎng)前景下，相信IM即時通訊系統(tǒng)將會進一步進化，成為物聯(lián)智能時代的IT基礎設施之一。
然而，到目前為止，即時通訊（包括其衍生的云推送平臺與服務）一直被賦予高難度、高投入的標簽，似乎成了強者的專屬，普通開發(fā)者和中小型IT公司的業(yè)務大都依賴現(xiàn)有的第三方產(chǎn)品或服務，先不說可能面臨高額的收費，從信息安全角度來說，把自己的客戶與業(yè)務建立在第三方服務的基礎上，也讓很多人心存顧慮。雖然業(yè)界也有各種較流行的開源實現(xiàn)，但其普及程度還比較低。另外，由于目前的開源實現(xiàn)，普遍基于較高級的應用層面（例如：XMPP），所以其實現(xiàn)較為復雜，普通技術人員不容易掌控和二次開發(fā)，并且越高級的應用，其通用性往往越低。
DDPush的出發(fā)點，是繞過已有的各種門檻和障礙，尋求另外一種簡單有效的方法，來嘗試折衷地實現(xiàn)移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)時代IM系統(tǒng)需求。DDPush的目的是幫助中小型應用和個人開發(fā)者，較容易地跨過IM系統(tǒng)的基本門檻，而不是挑戰(zhàn)和取代已有的業(yè)界標準和產(chǎn)品。DDPush，任意門推送服務器，只是另外一道門，也許能打開另外一個世界，但絕不是包含整個世界。
DDPush的思路，有點類似MQTT，重新定義了一套較簡單和低級的網(wǎng)絡通訊協(xié)議，來達到更小的流量、更高的效率、以及更好的通用性。而DDPush和MQTT的區(qū)別在于，DDPush更為簡單，放棄了QoS，只實現(xiàn)極為簡單的實時通訊需求，剩下的更多是交由應用層去控制。另外，DDPush實現(xiàn)并主推UDP方式，大為降低網(wǎng)絡通信成本和服務器承載成本，提高了容量和效率。
這個特點是DDPush與其他方案一個區(qū)別所在。DDPush認為可靠性、完整性，更多是應該由應用層去控制的，而不是網(wǎng)絡通信層。理由是在移動互聯(lián)網(wǎng)、無線物聯(lián)網(wǎng)的環(huán)境下，網(wǎng)絡本身就是非常不穩(wěn)定的因素（至少在很長一段時間內(nèi)都會是這樣），因此不能寄望其能完美地工作，需要應用層的保證。例如：當收到一封郵件的時候，應該是嘗試發(fā)出一個通知告訴郵箱所有者有新郵件達到，即使通知失敗了，也不影響直接登錄郵箱查看新郵件，同時也應保留再次通知的可能。設想一下，如果僅僅因為實時通知失敗了，就連新郵件都丟失的話，豈不是本末倒置？
因此，DDPush采取的策略是：不努力保證單次數(shù)據(jù)包的實時和必然到達，改為可能的多次通知直至終端主動確認，來提高“通知”的最終成功率。換句話說，DDPush犧牲部分的實時性，來換取更高的成功率，信息可能即時達到，也可能十幾分鐘后到達，甚至幾天后到達（如果終端幾天后上線的話），但一般總會到達。（當然，需要實時的時候還是可以實現(xiàn)的，因為DDPush的行為是可配置的，也支持TCP模式）
正因為如此，DDPush主推UDP協(xié)議，DDPush的通信協(xié)議格式就類似UDP協(xié)議，基于包的形式而不是流的形式，不依賴包的順序。不過，DDPush同時也用TCP實現(xiàn)了相同的協(xié)議，有需要的情況下只要打開TCP模式即可。這里需要聲明的是：UDP模式的服務器容量，是TCP的幾十倍甚至上百倍，請使用者自行權衡。
注：在設計DDPush的早期，作者也曾考慮引入部分QoS的功能，例如重發(fā)次數(shù)、重發(fā)策略等。但最后作者決定放棄大部分QoS功能，把這些問題留給應用層去控制，將更精確更實用，也能大大簡化DDPush的復雜度和提高容量與效率。畢竟，業(yè)務邏輯由應用層去控制，在線終端的數(shù)量由DDPush去保證，各司其職，應該是一種更恰當?shù)姆绞?。就好像郵件是否已讀，應該由郵件系統(tǒng)控制，而不是新郵件提醒功能去完成。
不過，DDPush并不是完全沒有QoS功能，只是采取了更簡單的，和MQTT三種QoS級別都不一樣的QoS功能：等待終端確認；外加應用層、終端實現(xiàn)的個性化配合手段，達到更大的自由度。
DDPush采取UDP協(xié)議的另外一個好處，是對終端設備的通用支持。對于常見操作系統(tǒng)（Windows、Android等）來說，網(wǎng)絡操作的支持完全不是問題，只是程序通用性的問題。而對于很多嵌入式Linux系統(tǒng)、普通硬件設備來說，要實現(xiàn)完整的網(wǎng)絡通信協(xié)議，特別是TCP這種高級應用層協(xié)議，是非常困難甚至有時候是不太可能的任務（與芯片、板卡的能力和成本有關），所以是本質(zhì)的通用性問題。而對于UDP，普通硬件設備和嵌入式系統(tǒng)則能較好地支持，因為其復雜度、難度都低很多，各方面要求也相應降低。DDPush采用二進制網(wǎng)絡通信協(xié)議，而不是文本協(xié)議，這也與很多硬件設備有更多的契合點。這些特點和MQTT很類似，不過目前MQTT協(xié)議是基于TCP協(xié)議而不是UDP。
對于XMPP等其他方式，很多開發(fā)者習慣直接使用其來傳遞信息內(nèi)容。而DDPush提倡傳遞“控制信息”，類似FTP的工作模式。即：通過DDPush來傳遞命令和控制信息，真正的內(nèi)容信息建議終端使用常見的HTTP GET或者新建TCP連接的方式，連接到應用服務器（而不是DDPush服務器）獲取。這里還會涉及安全驗證、內(nèi)容有效性等方面的需求，而DDPush不致力于解決類似的問題（MQTT則包括安全驗證等規(guī)則）。DDPush專注在“通知的下發(fā)和確認”方面。
DDPush不管是協(xié)議本身，還是代碼實現(xiàn)，其實都是很簡單的。因此，開發(fā)者很容易進行改造和二次開發(fā)，或者按照自己的需要重新改寫。整個DDPush服務器的Java代碼量很少，目前只有200K，編譯后的二進制文件不到100k，對于大部分開發(fā)者來說要讀懂，相信并不困難。這也是DDPush希望達到的效果，讓即時通訊、推送成為家常菜，而不是滿漢全席。
