在好几年前,就已经注意到DDPush这款推送中间件,不过看近来发展也还是停留在V1.0的基础上,不免惋惜!恰好最近正在深入研究Java Socket通信编程,也顺带再看看这款应用。官网地址:http://www.ddpush.net/
目录
第一步:下载DDPush消息推送服务器与Android安卓demo app安装文件
public boolean hasNetworkConnection()
public void onPushMessage(Message message)
DDPush Android UDP Demo 耗电、唤醒次数、唤醒时间详情
DDPush Android TCP Demo 耗电、唤醒次数、唤醒时间详情
历史版本1.0.02 (2014-08-29发布, 2014-11-21更新android示例工程)
DDPush 任意门 消息推送
DDPush是什么
DDPush (Dimension Door Push),任意门消息推送,是一款开源免费的单机千万级实时消息推送服务器,使用Java语言开发,具有简单、稳定、高性能、高容量等特点,适用于互联网、移动互联网、物联网、Android、智能设备、硬件设备等各种环境。
DDPush可以做什么
移动互联网消息推送
DDPush可实时推送信息到各种Android、Windows等手机和平板(即“透传”),并支持双向通信。DDPush支持自定义信息,信息的格式和内容可由开发者自行定义
IM实时消息系统核心组件
通过集成DDPush消息推送,可以开发各种IM实时消息系统,例如:聊天系统、社交App等。
物联网设备控制与交互
DDPush消息推送可作为一个实时控制中心,控制物联网中的各种硬件设备(硬件需支持网络通信),与之双向通信。
DDPush消息推送有什么优势
开源、免费
DDPush采用Apache License Version 2.0开源协议,可放心使用,只要您保留其许可证信息。
容量高,速度快,要求低
DDPush在线部分主要采用UDP协议(同时支持TCP协议),支撑1000万终端在线的服务器,最少只需要4G内存(不考虑变长自定义信息的情况下),单个主流双核CPU使用率低于75%。即:一部普通PC台式机的配置。
DDPush推送部分采取TCP协议和Java NIO非阻塞网络技术,普通PC可支持至少数千台应用服务器同时长连接推送信息到终端,每秒推送信息的速度在1万条以上
终端设备流量少,省电
采用DDPush,智能手机等终端设备在线一个月(空载的情况下),只需几百KB的上载流量,下载流量甚至可调节到为零。
DDPush提供的Android手机App示例demo,连续在线48小时耗电少于0.5 mAh(使用2G网络GPRS连接,经360省电王测试 >>>详情)
DDPush消息推送基于什么技术
DDPush基于自有的二进制网络传输协议(基于TCP和UDP),因此客户端可以支持各种类型的终端设备,包括各种智能手机、平板、智能设备、物联网硬件,和各种终端操作系统(包括: Android, Windows, Linux等)。
DDPush使用Java语言开发,因此服务端可运行在各种操作系统和服务器上。
DDPush消息推送 概述
IM(Instant Messaging)即时通讯系统
IM(Instant Messaging)即时通讯系统,从1996年ICQ的出现,到国际巨头割据的今天,已经深刻地影响了互联网,甚至人类社会的变化。从移动互联网时代开始,即时通讯系统更是加剧演变进化,除了iOS和Android提供全世界范围的Push Notification Service,还形成了各种开放的云推送平台与服务,成为巨头厮杀圈地的战场。在可预见的物联网前景下,相信IM即时通讯系统将会进一步进化,成为物联智能时代的IT基础设施之一。
然而,到目前为止,即时通讯(包括其衍生的云推送平台与服务)一直被赋予高难度、高投入的标签,似乎成了强者的专属,普通开发者和中小型IT公司的业务大都依赖现有的第三方产品或服务,先不说可能面临高额的收费,从信息安全角度来说,把自己的客户与业务建立在第三方服务的基础上,也让很多人心存顾虑。虽然业界也有各种较流行的开源实现,但其普及程度还比较低。另外,由于目前的开源实现,普遍基于较高级的应用层面(例如:XMPP),所以其实现较为复杂,普通技术人员不容易掌控和二次开发,并且越高级的应用,其通用性往往越低。
DDPush消息推送的思路
DDPush的出发点,是绕过已有的各种门槛和障碍,寻求另外一种简单有效的方法,来尝试折衷地实现移动互联网、物联网时代IM系统需求。DDPush的目的是帮助中小型应用和个人开发者,较容易地跨过IM系统的基本门槛,而不是挑战和取代已有的业界标准和产品。DDPush,任意门推送服务器,只是另外一道门,也许能打开另外一个世界,但绝不是包含整个世界。
DDPush的思路,有点类似MQTT,重新定义了一套较简单和低级的网络通讯协议,来达到更小的流量、更高的效率、以及更好的通用性。而DDPush和MQTT的区别在于,DDPush更为简单,放弃了QoS,只实现极为简单的实时通讯需求,剩下的更多是交由应用层去控制。另外,DDPush实现并主推UDP方式,大为降低网络通信成本和服务器承载成本,提高了容量和效率。
这个特点是DDPush与其他方案一个区别所在。DDPush认为可靠性、完整性,更多是应该由应用层去控制的,而不是网络通信层。理由是在移动互联网、无线物联网的环境下,网络本身就是非常不稳定的因素(至少在很长一段时间内都会是这样),因此不能寄望其能完美地工作,需要应用层的保证。例如:当收到一封邮件的时候,应该是尝试发出一个通知告诉邮箱所有者有新邮件达到,即使通知失败了,也不影响直接登录邮箱查看新邮件,同时也应保留再次通知的可能。设想一下,如果仅仅因为实时通知失败了,就连新邮件都丢失的话,岂不是本末倒置?
DDPush消息推送的策略
因此,DDPush采取的策略是:不努力保证单次数据包的实时和必然到达,改为可能的多次通知直至终端主动确认,来提高“通知”的最终成功率。换句话说,DDPush牺牲部分的实时性,来换取更高的成功率,信息可能即时达到,也可能十几分钟后到达,甚至几天后到达(如果终端几天后上线的话),但一般总会到达。(当然,需要实时的时候还是可以实现的,因为DDPush的行为是可配置的,也支持TCP模式)
正因为如此,DDPush主推UDP协议,DDPush的通信协议格式就类似UDP协议,基于包的形式而不是流的形式,不依赖包的顺序。不过,DDPush同时也用TCP实现了相同的协议,有需要的情况下只要打开TCP模式即可。这里需要声明的是:UDP模式的服务器容量,是TCP的几十倍甚至上百倍,请使用者自行权衡。
注:在设计DDPush的早期,作者也曾考虑引入部分QoS的功能,例如重发次数、重发策略等。但最后作者决定放弃大部分QoS功能,把这些问题留给应用层去控制,将更精确更实用,也能大大简化DDPush的复杂度和提高容量与效率。毕竟,业务逻辑由应用层去控制,在线终端的数量由DDPush去保证,各司其职,应该是一种更恰当的方式。就好像邮件是否已读,应该由邮件系统控制,而不是新邮件提醒功能去完成。
不过,DDPush并不是完全没有QoS功能,只是采取了更简单的,和MQTT三种QoS级别都不一样的QoS功能:等待终端确认;外加应用层、终端实现的个性化配合手段,达到更大的自由度。
通用终端的支持
DDPush采取UDP协议的另外一个好处,是对终端设备的通用支持。对于常见操作系统(Windows、Android等)来说,网络操作的支持完全不是问题,只是程序通用性的问题。而对于很多嵌入式Linux系统、普通硬件设备来说,要实现完整的网络通信协议,特别是TCP这种高级应用层协议,是非常困难甚至有时候是不太可能的任务(与芯片、板卡的能力和成本有关),所以是本质的通用性问题。而对于UDP,普通硬件设备和嵌入式系统则能较好地支持,因为其复杂度、难度都低很多,各方面要求也相应降低。DDPush采用二进制网络通信协议,而不是文本协议,这也与很多硬件设备有更多的契合点。这些特点和MQTT很类似,不过目前MQTT协议是基于TCP协议而不是UDP。
使用DDPush消息推送的方式
对于XMPP等其他方式,很多开发者习惯直接使用其来传递信息内容。而DDPush提倡传递“控制信息”,类似FTP的工作模式。即:通过DDPush来传递命令和控制信息,真正的内容信息建议终端使用常见的HTTP GET或者新建TCP连接的方式,连接到应用服务器(而不是DDPush服务器)获取。这里还会涉及安全验证、内容有效性等方面的需求,而DDPush不致力于解决类似的问题(MQTT则包括安全验证等规则)。DDPush专注在“通知的下发和确认”方面。
事情其实很简单
DDPush不管是协议本身,还是代码实现,其实都是很简单的。因此,开发者很容易进行改造和二次开发,或者按照自己的需要重新改写。整个DDPush服务器的Java代码量很少,目前只有200K,编译后的二进制文件不到100k,对于大部分开发者来说要读懂,相信并不困难。这也是DDPush希望达到的效果,让即时通讯、推送成为家常菜,而不是满汉全席。
DDPush消息推送 快速开始
欢迎来到DDPush快速开始,本页面将引导您快速体验DDPush的基本功能,请按照以下三个步骤操作:
第一步:下载DDPush消息推送服务器与Android安卓demo app安装文件
第二步:运行DDPush消息推送服务器
第三步:安装与运行Android安卓demo app
第一步:下载DDPush消息推送服务器与Android安卓demo app安装文件
请点击以下链接下载文件:
DDPush服务器
安卓客户端app示例(UDP)
安卓客户端app示例(TCP)
第二步:运行DDPush消息推送服务器
解压DDPush消息推送服务器压缩文件到您电脑的某个目录(路径不要包含中文或空格),您将看到2个目录与4个文件。
目录:lib, logs
文件:start.bat, start.sh, console.bat, console.sh
如果您在使用Windows操作系统,请执行start.bat文件(注:勿双击bat文件,请于CMD窗口中运行);如果您使用的是Linux系统,请执行start.sh文件。这里使用Windows系统演示,执行start.bat文件。如果您看到类似以下的信息,说明DDPush服务器已经运行:
您也可以检查logs目录下是否有ddpush.out日志文件输出来判断DDPush是否在运行。此外,您还可检查DDPush的默认端口是否正在监听。
如果您要停止DDPush消息推送服务器,请新打开一个命令行窗口,执行命令:"console.bat stop",DDPush服务器将会停止
Linux系统下的操作与Windows类似,差别在于Linux系统下执行的是start.sh和console.sh脚本。
注意:如果您通过ftp单独上传sh脚本文件到Linux服务器,注意不要破坏文件格式,如出现无法运行sh脚本的情况,请尝试使用dos2unix命令转换文本格式,并确保sh文件权限为可执行
第三步:手机安装与运行Android安卓demo app
请使用Android手机分别安装第一步下载的另外两个apk文件。您也可以使用两台手机分别安装,以达到更现实的体验效果
安装完毕后,打开两个app,配置服务器IP为您在第二步中运行DDPush消息推送服务器的机器IP,见下图
按照上图的示例,两个app分别设置不同的用户名,并把目标用户名设置为对方,以测试互相推送信息。这里是user01和user02,各端口号采用默认值。
注意正确设置服务器IP为第二步中DDPush消息推送服务器运行机器的IP,并且手机能正常访问网络与该IP。
分别点击"开始测试"按钮后,即可通过下面的按钮来互相发送推送信息,见下图收到的实时推送信息示例。(若延时数分钟后才收到推送信息亦属正常情况,请检查网络是否畅通,服务器IP地址是否可达)
当然,您也可以只安装其中一个app demo,然后自己给自己发送推送信息,只要把用户名、目标用户名设置为同一个字符串即可。
DDPush消息推送 一分钟集成
集成使用DDPush消息推送服务器,只需要简单继承DDPush提供的Java客户端基类,并实现三个简单的函数,即可使用DDPush服务,不需要了解客户端与服务端网络协议交互的细节。
DDPush提供的客户端基类,已经满足大部分的应用场景。此外,DDPush提供的Android App客户端示例,还实现了Android开发中的后台长时间运行的service服务,您可以直接使用。
若DDPush提供的现成基类和示例无法满足您的应用场景,你可以改写或者重写DDPush客户端。这并不会很困难,但需要您了解DDPush自身的网络协议。当然,这个也不会是很困难的事情。
马上开始!
第一步,继承并实现客户端抽象基类
继承UDP或者TCP客户端抽象基类
UDP:public class MyUdpClient extends org.ddpush.im.v1.client.appuser.UDPClientBase
TCP:public class MyTcpClient extends org.ddpush.im.v1.client.appuser.TCPClientBase
实现三个抽象函数
public boolean hasNetworkConnection(){}
public void onPushMessage(org.ddpush.im.v1.client.appuser.Message msg){}
public void trySystemSleep(){}
public boolean hasNetworkConnection()
该函数主要用于智能终端,判断当前是否有可用的网络连接,以达到省电的目的(若无网络连接则不尝试网络操作)。不同的终端检测网络情况的方式会不一样,所以DDPush客户端示例要求您的实现自行判断网络连接是否可用。如果是PC版软件不需考虑省电,可简单返回true,哪怕实际上没有可用的网络连接。
public void trySystemSleep()
该函数同样主要用于智能终端,在客户端不需要发送心跳包,并且服务端无推送信息的时候,尝试系统休眠,达到省电的目的。PC版软件可以直接将该函数留空,不做任何处理。Android则可能要考虑释放WakeLock以进入系统休眠状态。
public void onPushMessage(Message message)
该函数是客户端处理推送信息的业务入口函数。当客户端收到服务端的推送命令,将自动发送确认包,然后调用该函数。所以该函数内或其调用的其他函数,应该确保信息的正确处理,因为正常情况下该推送信息已经确认,极可能不会再次收到通知。
DDPush现成的客户端基类,会在该函数返回后,再调用trySystemSleep()函数。因此该函数内不用考虑保有WakeLock等防止系统休眠的操作。
第二步,运行客户端
UDP客户端:
MyUdpClient myUdpClient = new MyUdpClient(uuid,1,"192.168.1.100",9966);
myUdpClient.setHeartbeatInterval(50);//50秒一次心跳,可由您动态调节
myUdpClient.start();
TCP客户端:
MyTcpClient myTcpClient = new MyTcpClient(uuid, 1, "192.168.1.100", 9966, 5);
myTcpClient.setHeartbeatInterval(50);//50秒一次心跳
myTcpClient.start();
若网络发生变化,客户端会自行处理。
程序退出关闭客户端:myUdpClient.stop()或者myTcpClient.stop()。
第三步,应用服务端推送信息
Pusher pusher = new Pusher(serverIp,port, timeoutMills);
boolean result = pusher.push0x20Message(uuid,message);
注:这个步骤一般应该是应用服务器向DDPush消息推送服务器发起,但在DDPush Android demo工程里面,为了方便直接在客户端调用,只是为了演示如何编程。
Android客户端
在Android App开发中,会涉及到其他特有的因素,例如service的持续运行、WakeLock的控制等,并非简单继承基类实现以上三个函数就能正常工作。请参考DDPush提供的Android客户端示例App
安卓demo apk耗电分析
目前全世界所有智能手机的电池续航能力都是瓶颈,因此app耗电的大小是app开发者非常关注的一个点,特别是长期联网运行的app。
DDPush提供的Android安卓App客户端demo,一方面展示DDPush的使用,另外一个方面也提供了现成的,集成了在线服务的Android开发示例。该示例通过了一系列的长期运行测试,确保在省电省流量方面达到较好的水平。
48小时在线测试结果(UDP,TCP,微信)
以下内容展示了Android demo app在GPRS连接(2G网络)下连续空载运行48小时后的耗电、唤醒时间统计,并与微信作比较。(使用WakeLock Detector和360省电王测试)
以上图片显示,GPRS连接(2G网络)下连续运行48小时,DDPush的UDP demo、TCP demo和微信的唤醒次数、总唤醒时间基本持平,在20至25分钟左右。
DDPush Android UDP Demo 耗电、唤醒次数、唤醒时间详情
如图所示,48小时内UDP Demo唤醒605次,唤醒时间21分16秒,耗电0.4 mAh
DDPush Android TCP Demo 耗电、唤醒次数、唤醒时间详情
如图所示,48小时内TCP Demo唤醒606次,唤醒时间20分18秒,耗电0.3 mAh
微信 耗电、唤醒次数、唤醒时间详情
如图所示,48小时内微信唤醒721次,唤醒时间25分41秒,耗电0.8 mAh
360省电王评价
如图所示,360省电王对UDP和TCP演示app的耗电评价是"此软件耗电极少,适合长期后台运行,请放心使用"
注:360省电王版本为2.2.2.0001
耗电小结
综上所述,在2G网络GPRS连接情况下,TCP与UDP两种方式的耗电基本没差别,并且对手机电池的消耗较少,加上与微信的对比,证明方案可行。
DDPush消息推送 网络流量分析
网络流量,特别是无线电话网络流量,有时候并不是它所应该的那么便宜。即使不考虑价格因素,更快的速度、更高的通信效率这些目标也决定了我们不能无节制地消耗流量,至少不环保。实际上,DDPush从设计的初期开始,就以尽可能少的网络传输作为核心目标。
终端上载流量
根据DDPush当前的通信协议,终端上传的一个UDP数据包,有效数据最少为21字节。加上UDP和IP包的首部长度,不会超过70字节。移动互联网环境下,假设终端每5分钟发送一次心跳包(这个是建议值,过于频繁可能导致智能终端(手机)电池电量消耗过快),则一个月的上载数据量为70x12x24x30=604800字节,约合591K。这就是DDPush客户端所消耗的上载流量(完全空载运行情况下)。
实际情况可能有些不一样,因为当手机处于非休眠状态的时候(智能手机大部分时间都是休眠的),我们可能希望心跳的间隔小一些,以便更及时地收到实时信息,又不至于消耗过多的电(非休眠状态下是非常耗电的,不在乎多耗一些了)。所以,DDPush客户端的上传流量会比上述的591K稍多一些。
终端下载流量
DDPush终端的下载流量远比上传流量少(详见协议内容和使用文档),而且在无信息通知的情况下,DDPush服务器可通过参数配置成不下发心跳,这时将不会有下载流量产生。当然,这种情况下终端可能无法判断自己是否在线。
服务器流量
对于服务器而言,主要的流量是入站流量,这与大部分互联网服务恰恰相反(例如HTTP服务就是典型的入站流量小,出站流量大)。其实这也是IM系统的一个特点。根据DDPush的测试,独享百兆带宽出口(100m bits/second)的网络,可支持一千万以上终端同时在线(5分钟一次心跳,平均每秒3.33万个UDP心跳包,完全是DDPush的能力之内,这时UDP包的成功率将近100%)
什么?独享百兆出口带宽太贵了?拜托,一千万在线客户,您已经是土豪了,就别在乎那一点点带宽费用了......
小结
使用DDPush消息推送,终端设备基本可以忽略DDPush客户端自身的流量;而服务端的流量,相对其收益来说,成本将是非常低的。
UDP对TCP
TCP还是UDP?长连接如何实现?如何实现心跳机制?心跳的间隔如何确定?这些问题都是讨论即时通讯、消息推送等类似话题时,几乎一定被问到的问题。这里尝试正本清源一下。
互联网、移动互联网网络环境
在分析到底应该使用UDP还是TCP之前,有必要先讨论一下互联网与移动互联网的网络环境特点。
互联网的网络基础建设,经过十几年长期的发展,已经较为稳定和成熟,PC终端、操作系统的能力也达到了较高的水平。
而移动互联网,由于涉及到无线电话网络基站、2G、3G和4G技术的不断发展,其稳定性、带宽、资源分配等各方面虽日趋完善,但当前终究还有不少问题的存在。另外,由于移动互联网其“移动”的本质,加上智能终端设备(智能手机、平板电脑)的发展较晚,目前还在不断演变的情况,与互联网相比,移动互联网还是低速、不稳定、终端能力稍弱的情况。而且由于其“移动”本质,短时间内很难达到互联网的质量。
所以,在互联网的环境里面,网络应用程序由于网络设施、操作系统的成熟,开发使用起来比较容易,资源也较为充足。而移动互联网还是要“斤斤计较”。
智能终端电池续航能力,系统休眠
智能终端设备的电池续航能力始终是技术瓶颈。在连续使用的情况下,绝大部分智能设备电池无法支持两个小时以上。所以在没有外部电源的情况,智能终端设备必须频繁、长时间休眠,这将极大地影响两种网络环境下的网络应用场景。
IPv4资源、端口资源
这个话题往往被很多人忽略,但它有着至关重要的影响。虽然大部分人都很清楚IP地址的紧缺导致的动态IP分配的必然,却忽略了由于IP地址不足引起的端口资源不足。
由于需要动态分配IP地址(这里不仅仅指互联网入口的IP,还包括局域网内部的IP),路由器的工作原理都是经过端口映射,把内部网络(包括PC、手机、平板、Wifi、2G、3G、4G)IP与端口映射成外部IP(通常是公网IP)和对应的端口,并维持这个映射关系,才能正常地修改、转发报文信息,保证内部各个ip、端口与外部的各个ip、端口的通信。
然而,单个IP地址的端口资源是有限的,理论上限是65535个端口。对于普通宽带路由器来说,这个已经很充足了。但是!对于大型的网络服务、网络主干接入点等来说,如果IP资源不足,每个IP几万个端口的资源很快会耗尽,从而影响正常通讯。
端口映射老化时间
正因为如此,所有的路由器都会为每个端口映射关系设置老化时间,如果老化时间倒数到0,则端口映射关系失效,该端口被释放给其他连接使用。如果端口全部耗尽,则无法再新建内部与外部的网络连接。
端口映射老化时间,比很多人想象中的要短很多。一般的家用宽带路由器,老化时间一般是两三分钟;在有线宽带运营商接入部分,老化时间可能少于两分钟。在无线电话网络运营商接入部分(例如GPRS连接),老化时间甚至不超过一分钟!
也就是说,任何一个网络通讯(不管是TCP或UDP),如果几分钟之内没有网络报文传输,其占用的IP地址端口将被路由器回收。这个时候该次通信必将终止,不管TCP还是UDP,神马都是浮云。
更残酷的事实是,互联网可认为是由无数个路由器连接而成的,一个网络通信往往需要通过n个路由器,每个路由器都会为一次通信建立自己的端口映射。只要其中一个路由器回收其端口,则整个通讯中断。
这也是很多人疑惑为什么TCP的KeepAlive参数无法保证长连接的原因。TCP的KeepAlive默认是两个小时(而且该参数还是TCP的可选实现,不是必然实现),在路由器端口映射老化时间的影响下,必然无法发挥其作用。实际上,该参数在单一的局域网内才可能被使用上,还要依赖具体的操作系统。
由于路由器端口映射的存在,加上智能终端频繁、长时间的休眠,TCP长连接的实用性在移动互联网情况下极大地打了折扣。
也因为如此,IM系统必须实现所谓的心跳包机制,以保持端口映射关系的老化时间不会减少到0而被回收,从而避免连接中断。
服务端承载能力
不管是UDP还是TCP,最终都是应用服务端的设备去提供服务的。而TCP由于提供了安全可靠的流服务,其对计算机、网络资源的消耗是远远大于UDP协议的。对于配置较好的主流服务器,配备大量的内存(数十G至上百G内存),与高速的磁盘、网卡,是能同时支持数百万个TCP连接的。不过这里需要较专业的服务器设置,需要调整不少系统参数,再加上服务程序的配合。另外,TCP连接的建立、维持与释放,都是需要较昂贵的计算、网络资源的。
终端在线服务,若是一个较为简单的服务,未必使用上TCP众多的高级功能,但承受TCP的昂贵成本,未必值得。如果能用UDP来提供服务,单服务器的承载能力,是可以去到TCP服务的数十倍,甚至上百倍的增长。这也是为什么DNS这种并发数巨大的服务器提供UDP接口的原因。
另外,上百万TCP连接的网络服务,其编程的难度、程序复杂度、调试难度、服务器运维成本、网络成本等都远远高于UDP。
而UDP编程,与上百万个终端通讯的难度与成本则低很多。如果提供的网络服务不是基于流的服务,也允许一定的失败机率(例如P2P),则UDP往往是更适合的方式。
高级应用网络通讯要求
不过,即时通讯系统、推送系统一方面提供终端在线服务,另外一方面也需要考虑内容信息的完整性和安全性。毕竟信息的丢失,或者通讯的被窃听,都是难以接受的。而TCP不管在网络层的可靠性控制,还是在应用层的安全支持(例如HTTPS),都为应用提供无法替代的强大功能和便利。
结论
综合以上所述,其实答案也呼之欲出。
现在的即时通讯系统、推送系统,既面对移动互联网的不确定性,又面对智能终端频繁的系统休眠、网络切换,还要考虑服务端的承载成本,对于在线服务而言UDP是比TCP更适合的方式。但是由于数据完整性、安全性的需要,又不应完全放弃TCP的可靠与安全。
所以,DDPush认为,更恰当的方式应该是:两种通信协议同时使用,各有侧重。UDP用于保持大量终端的在线与控制,应用与业务则通过TCP去实现。这个和FTP服务控制与数据分离,采取不同的连接,有异曲同工之处。
事实上,这个也是即时通讯巨头QQ所采用的方式。早期的时候,QQ还是主要使用TCP协议,而后来就转向了采用UDP的方式来保持在线,TCP的方式来上传和下载数据。现在,UDP是QQ的默认工作方式,表现良好。相信这个也被沿用到了微信上。
简单的考证:登录PC版QQ,关闭多余的QQ窗口只留下主窗口,并将其最小化。几分钟过后,查看系统网络连接,会发现QQ进程已不保有任何TCP连接,但有UDP网络活动。这时在发送聊天信息,或者打开其他窗口和功能,将发现QQ进程会启用TCP连接。
最后,需要明确指出的是:DDPush只专注在保持和控制终端在线方面,而对于具体的应用和业务,DDPush是基本不提供任何支持的。
DDPush 任意门推送 1 下载
欢迎来到DDPush任意门推送下载页面。该页面提供DDPush最新版本的下载链接,也包括旧的历史版本。
注:Android示例工程app中使用到的ddpush相关类库jar包,代码实际是ddpush server中的client部分。
系统要求
Java 6.0或以上
最新版本1.0.03 (2015-01-02发布)
- 修复了app server端连续推送混合信息时,可能引起的挂起。
- 客户端tcp超时默认设置改为300秒。
- 控制台取消仅允许本地网络访问的限制,可远程网络连接控制台。
- Android示例客户端app无更新。
二进制发布
DDPush Server v1.0.03
安卓客户端App示例(UDP)
安卓客户端App示例(TCP)
源码发布
DDPush Server v1.0.03
安卓客户端App示例(UDP)
安卓客户端App示例(TCP)
历史版本1.0.02 (2014-08-29发布, 2014-11-21更新android示例工程)
- UDP客户端基类UDPClientBase.java增加getLastReceivedTime()方法,记录服务器最后UDP包时间,可用于IM系统客户端自我判断是否在线或超时
- 修复了TCP模式下,自定义信息长度较长时引起数据紊乱的Bug。该Bug不影响UDP模式客户端。
- 2014-11-21更新了android示例客户端,包括TCP和UDP两个工程,解决了部分安卓版本“很抱歉,‘xxxx’已停止运行”的异常提示。
二进制发布
DDPush Server v1.0.02
安卓客户端App示例(UDP)
安卓客户端App示例(TCP)
源码发布
DDPush Server v1.0.02
安卓客户端App示例(UDP)
安卓客户端App示例(TCP)
历史版本1.0.01 (2014-08-01)
DDPush诞生了
二进制发布
DDPush Server v1.0.01
安卓客户端App示例(UDP)
安卓客户端App示例(TCP)
源码发布
DDPush Server v1.0.01
安卓客户端App示例(UDP)
安卓客户端App示例(TCP)