客户端与服务端实时通信结合实际场景，求助解决方案~~

Joseph · 6 年前

场景：
      1.服务端不定时的同时给多个Android客户端推送数据(数据最大的约为10K)
      2.客户端每隔半个小时或者一个小时向服务端上报数据
      3.遇到特殊事件立即上报，后端要立刻做出响应。
      4.为以后考虑设计的服务端至少要支撑10W--20W客户端，7*24小时在线，还有支持客户端和客户端的通信。

遇到的问题：
      1.随着业务逐渐复杂，客户端与服务端的交互越来越频繁，之前设计的HTTP轮询方式压力就大了。。。终究不是长久之计
      2.移动推送服务使用无线移动网络，网络质量不稳定。
      3.部分设备在电梯中，网络奇差！

目前设计方案还没确定下来。。。。望各位大佬给点意见。

小弟感激不尽。

2 楼: JackJiang · 6 年前

你这个场景有几个特点：
1）数据来往不密集；
2）网络环境不优越（或者说有的客户端处于非常极端的情景中（）；
3）需要双向实时通信；
4）并发在线数也不算小。

我个人建议你优先考虑UDP协议：
1）它很经济，必竟数据来往不密集，心跳包可以放的长一些，这样包括客户自已在内，流量、电量消耗都比较经济，而且服务端也轻松一些；
2）能解决极端网络的情况（虽不完美，但肯定不会比TCP差，或者极端情况下，tcp是搞不定的）；
3）唯一要纠结的是，udp最大包长度可能没法达到10K（《UDP中一个包的大小最大能多大》、《
不为人知的网络编程(六)：深入地理解UDP协议并用好它》）。

不过第3点可以进行规避，比如推的并不是全量内容而是一个指令（客户端收到指令后，自已用http短连接拉一次）。

以上只是我的建议，仅供参考。

3 楼: Shahala · 6 年前

你直接研究一下群主的 MobileIMSDK吧，自已造轮子太难弄了~~~

4 楼: Joseph · 6 年前

引用：JackJiang 发表于 2018-12-20 18:28
你这个场景有几个特点：
1）数据来往不密集；
2）网络环境不优越（或者说有的客户端处于非常极端的情景中 ...

非常感谢您的建议

您这个接收指令，HTTP在去拉信息就很灵性了。之前是自己脑子死板了，没想到变通。

5 楼: Joseph · 6 年前

引用：Shahala 发表于 2018-12-20 21:30
你直接研究一下群主的 MobileIMSDK吧，自已造轮子太难弄了~~~

是的，群主的MobileIMSDK还是很厉害的。

6 楼: JackJiang · 6 年前

引用：Joseph 发表于 2018-12-21 11:25
非常感谢您的建议
您这个接收指令，HTTP在去拉信息就很灵性了。之前是自己脑子死板了，没想 ...

嗯嗯，移动端都这么玩。

本文目录

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

本文目录

MobileIMSDK(v6.5精编版)

MobileIMSDK-Web(有偿开源)

RainbowAVnew(有偿开源)

RainbowChat(技术转让)

RainbowChat-Web(技术转让)

精华之王

白金版主

终身成就

即时通讯网

友情链接[友链交换]

关于

微信公众号new

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

即时通讯网　