基于 XMPP 协议的 GPRS DTU ， 实现真正的点对点通讯
本帖最后由 stopfan 于 2012-4-9 22:29 编辑最近在研究关于DTU相关的东西，发现现在大部分DTU 是基于 移动GPRS网络来与上位机进行通讯的。
这样的话，就有一个很重要的问题，GPRS 网络是通过NAT或HTTP代理来与Internet进行互联的，因此它不具备对外可见的IP地址。
一般我们要与DTU进行数据通讯时，一般都是找一个拥有公网IP的上位机，打开某个特定端口，然后等待DTU进行主动连接，才能进行
正常通讯。
这种被动的连接方式，针对个人或是小型应用来说无疑是致命的，没有时间或是精力来维护和假设一个 Always-online 的服务器。
基于这种现状，愚人正尝试改变GPRS DTU的这种弊端。
解决这一问题首先要找一个 可靠而强劲的 数据终端服务器
其次是要符合某种标准，方便大范围的开发和受用
百度大神说：
XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程 序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。
有这么好的一个协议我们不得不用啊，而且这个协议也是被google所支持的。这样要完成这项任务的两个必要条件都具备了。
接下来就是 在DTU中实现一套XMPP客户端。上位机的XMPP客户端就不用说了，有N种开源的。
我选用的DTU硬件平台为 STM32 + DM9000 ， 成功后再转向 GPRS模块
软件上跑一个 RTthread
软件方面实现起来甚是繁琐，由于GOOGLE XMPP协议服务的加密协议时TLS的，首先需要实现一个TLS客户端，然后XMPP协议实际上是XML流的方式进行的，因此还需要一个足够精简的XML解析库，像STM32这种没有MMU的
东西实现起来真的不是很容易。不知道有没有牛人实现过STM32上的XML解析器。
TLS客户端基本上跑通了，能够与talk.google.com进行密码协商，能够传输数据。接下来的主要任务是XML库的实现，参考网上很多开源XML库，大多都比较复杂移植起来能把人整死。
还有那rfc3920的XMPP协议规范
下面我已经能够进行用户登陆的会话。
SEND DATA [<?xml version='1.0' ?><stream:stream to='gmail.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'xml:lang='en' version='1.0'>]
RECV DATA [<stream:stream from="gmail.com" id="BD47B77F76A4BDD4" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">]
RECV DATA [<stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms></stream:features>]
SEND DATA [<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'>AGxpdWQuY24ud</auth>]
RECV DATA [<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>] // 这是登陆成功的标记
SEND DATA [<?xml version='1.0' ?><stream:stream to='gmail.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'xml:lang='en' version='1.0'>]
RECV DATA [<stream:stream from="gmail.com" id="A806543B2E055D55" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">]
RECV DATA [<stream:features><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/></stream:features>]
SEND DATA [<iq id='uid:d79bf9b8:00000001' type='set' from='liud.cn.test@gmail.com' xmlns='jabber:client'><bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'><resource/></bind></iq>]
基本就是这个样子，如能坚持下去能够跑通的话，将来控制DTU只需要找到任意一个能够联网的地方 就能与DTU进行会话，甚至用手机下载一个GTALK客户端，就能直接会话，而且开源的XMPP客户端
遍地都是，可以随意开发上位机平台。
基本思路就是这些，不知道这个有没有用途。。。。。大家提提意见。希望这次搞的不会像前一阵子搞的STM32+8686跑WIFI那么没有用武之地了。。。。。
开设此贴，记录一下开发过程。。。。 与大家共同分享。。。 给楼主推荐 The Expat XML Parser, http://expat.sourceforge.net/
我眼中最棒的开源XML parser，功能极其强大，很多被一些商业大型软件直接引用。纯C语言实现，STM32下移植应该不费力。 想法很好，慢慢研究！ 本帖最后由 HYLG 于 2012-4-9 23:50 编辑
怎样实现GPRS模块之间传送彩信并且省钱。 虽然看不太懂，但来源的东西要支持 现有的XML Parser库编译出来一般都比较大，不适合STM32使用。
XML实在太啰嗦太啰嗦了，要节约STM32的那可怜的空间，要支持Stream解析才行。
支持Stream解析的库我知道的有pugixml(C++), expat(C)
还有个ezxml库本身不大，不过不支持stream解析，内存分配也是用的默认的malloc()/free()，对于STM32负担可能重一点。
这两个是HTTP协议，处理起来比XML简单多了（不必使用HTML）。
其实用Google App Engine架服务器的方法比较好，不过不满足你的稳定，因为现在就不能DNS解析了，只能IP，也不能保证哪天也被封。
Sina App Engine有一定的免费数额，初期的话不用交钱。
不过最佳办法仍然是自架服务器，自由度大得多，就是完全与你要求相左了。
我有几个问题：
1. 这种XML类型的协议用在GPRS DTU终端上，挺费流量；比如，我可能只是想传一个控制命令，用几个字节就搞得，加上XML这些OVERHEAD后就要用几十个字节甚至几百个字节去传输，流量不用花钱么？
2. 如何列出所有在线的DTU？
3. DTU的心跳包大概需要发送多少个字节？
我觉得还是自己架设服务器比较方便，除非你想用DTU和朋友聊天，呵呵。也许定义一个公共的DTU开放协议很有必要，这样形成标准后，大家可以基于这个DTU开放协议使用公共的服务器。
不懂，感觉楼主的研究思路不错，支持开源，支持楼主~~ 虽然看不太懂，但来源的东西要支持 lqs10 发表于 2012-4-10 08:54 static/image/common/back.gif
我有几个问题：
1. 这种XML类型的协议用在GPRS DTU终端上，挺费流量；比如，我可能只是想传一个控制命令， ...
您提出的这几个问题确实挺实际，这也是我设计初期所考虑的问题。
1. 现在用手机整天挂QQ的大有人在吧？也没见他们倾家荡产过。 而且QQ那破玩意，肯定要比XMPP要高很多。XMPP协议虽然是XML但是他每次只发送一个小的MESSAGE节点。流量虽然有所增加，但是没有想象中的那么庞大。
2.关于DTU的访问列表，可以想象一下，任何一款IM通讯工具的IM列表。每个DTU都对应一个JABBER账号就可以了，而且互不干扰。
3.关于心跳包，只要保证TCP正常联通状态，剩下的交给XMPP服务器去定义就好了。其实这些都可以参考，手机24小时挂QQ的模型。
关于制定一套DTU标准，这确实很有必要，但是XMPP还是相对比较符合DTU的开发的，因为他的客户端协议相对简单，而且服务端协议也是支持分布式的，能够容纳下成千上万个DTU终端的连接。
XMPP协议能够自由扩展，因此随意传送任何协议都不受限制，包括语音视频的传送。 给加大推荐一个 开源的 SSL 协议 matrixssl 。
matrixssl，C语言实现l，支持跨平台，国外已经能在FreeRTOS上跑。我目前正在尝试，将其移至到RTthread中去，来替换我自己实现的SSL客户端。这样RTthread就能够支持全面且完善的SSL/TLS通讯了。
移至成功后 打算 提交给RTthread 官方，也算是为中国开源献出一份薄力吧 {:titter:}{:titter:}{:titter:}{:titter:} 本帖最后由 theophilus 于 2012-4-10 12:50 编辑
QQ的消息是二进制的。
即使是GTalk, Android上都是Protobuf, 而不是XML，云推送服务也是用的Protobuf。
不过，支持你对SSL/TLS的研究，这个比XMPP有用多了。
Edit:
这个比XML有用多了。 => 这个比XMPP有用多了。
SSL这个很有意义，强烈这次。 我正在做的和这个差不多，进行一半了，强烈建议XMPP协议，,PS上论坛居然要用代理 stopfan 发表于 2012-4-10 11:16 static/image/common/back.gif
给加大推荐一个 开源的 SSL 协议 matrixssl 。
matrixssl，C语言实现l，支持跨平台，国外已经能在FreeRTOS ...
SSL只是安全协议，应用层还是要自己定义啊！~ ljt80158015 发表于 2012-4-10 14:26 static/image/common/back.gif
SSL只是安全协议，应用层还是要自己定义啊！~
对，TLS 是基于TCP/IP协议的一种上层协议。
我现在已经和GOOGLE XMPP 服务器建立起了 TLS 连接，并且能够请求到大部分的 HTTPS 的网站的 HTTP请求。 自己建 XMPP 服务器难度大么？
依靠GOOGLE也不保险啊！~ ljt80158015 发表于 2012-4-10 14:59 static/image/common/back.gif
自己建 XMPP 服务器难度大么？
依靠GOOGLE也不保险啊！~
网上能搜到的有N种 XMPP服务器。
Openfire (Wildfire) 3.x
授权: GPL or 商用
操作系统平台：所有(使用Java开发)
XMPP Jabber 协议实现情况：98%
Tim 评价：
安装和使用非常简单，安装后进入Web界面进行2~3分钟的配置所有的东西都设好了。使用Java语言开发，在目前Java开发人员到处普及的情况
下进行维护和扩展的成本非常低。在我的测试中加上 Connection Manager 的情况下单台服务器可支持 30 万并发用户。缺点是目前还不支持
cluster。如果企业内部部署IM使用 Wildfire + Spark 是最佳的组合。
安装方法见：http://www.blog-dragon.com/2007/10/jabber-xmpp-openfire-spark.html
XMPP不错！~ 上次去商场看到创维云电视的演示，手机可以控制电视机，感觉就是这种模式的。 已经移植了openssl xmpp协议移植完，看见楼主推荐matrixssl 准备这个也移植完了，替换openssl，只剩下一个库了，移植这个真学了不少linux东西 想法很好，慢慢研究！{:shocked:} sakmb 发表于 2012-4-10 20:45 static/image/common/back.gif
xmpp协议移植完，看见楼主推荐matrixssl 准备这个也移植完了，替换openssl，只剩下一个库了，移植这个真学 ...
你是居于linux的啊，做什么具体的应用呢？ 要是能利用 mcu+grps模块去解析 qq的wap网页然后登陆 进去，向外面发信息 可能么？ richards 发表于 2012-4-11 18:51 static/image/common/back.gif
要是能利用 mcu+grps模块去解析 qq的wap网页然后登陆 进去，向外面发信息 可能么？ ...
理论上是可行的，但是QQ这种垃圾东西协议时保密的 ，而且登陆多次的时候会有验证码的，而且WAP必然是固定时间刷新数据的，很浪费流量的而且实时性不高。不过XMPP协议时任何IM互联的一种趋势，将来任何IM都将会支持XMPP协议的。。 XMPP协议,客户端与服务端的连接是长连接，还是短连接？ ljt80158015 发表于 2012-4-12 08:44 static/image/common/back.gif
XMPP协议,客户端与服务端的连接是长连接，还是短连接？
就我所知，XMPP是需要长连接的（正常情况）。不然的话就要轮询，有3个主要缺点，1. 不必要的对服务器请求的开销； 2. 额外的流量开销； 3. 对实时性的影响。
theophilus 发表于 2012-4-13 00:54 static/image/common/back.gif
就我所知，XMPP是需要长连接的（正常情况）。不然的话就要轮询，有3个主要缺点，1. 不必要的对服务器请求 ...
如果是长连接，几十上百万个连接到服务器，服务器能承受得了？ ljt80158015 发表于 2012-4-13 08:44 static/image/common/back.gif
如果是长连接，几十上百万个连接到服务器，服务器能承受得了？
我觉得你是跟服务器并发连接书搞混了，上百万的并发，要达到高吞吐率确实有难度。
但是。。。 长连接，记住有很多连接是闲置的（IM又不是随时都在发送、接收数据，使用PUB/SUB模式只会按需发送、接收）。
除非你用select轮询，不然那些空闲的TCP连接，你使用epoll/kevent/IOCP是不会造成性能损失的（当然会占用内存）。
theophilus 发表于 2012-4-13 09:11 static/image/common/back.gif
我觉得你是跟服务器并发连接书搞混了，上百万的并发，要达到高吞吐率确实有难度。
但是。。。 长连接， ...
还有一点，XMPP协议 是支持分布式的。。。 如果有一天，你真能为止成千上万的客户端，大可以搞个集群。。。 本帖最后由 stopfan 于 2012-4-17 09:03 编辑
在STM32 上 基于RTthread XMPP 客户端基本完成。能够连接Google的XMPP服务器。实现消息的发送和好友列表及其状态的获取。
找时间上传一个演示视频，演示使用GTalk客户端来控制LED等的实验。还有IPhone , Ipad ,Android 对LED进行控制的种种实验。内网IP即可完成实验。 兄弟，你好，我想问问，后来你这个xmpp弄的如何呢，稳定么，能否长时间工作呢，那个xml parst 是然后解决的呢，谢谢。 aico.liu 发表于 2012-12-5 15:30 static/image/common/back.gif
兄弟，你好，我想问问，后来你这个xmpp弄的如何呢，稳定么，能否长时间工作呢，那个xml parst 是然后解决的 ...
马上我就会有相关DTU出来 我表示没有看懂 这个想法很好，关键是找一个稳定的xmpp服务器 楼主还在继续此项目吗？ 还在继续吧,只是ID被封了. 屌爆了，之前没看到 楼主弄得怎么样了
页:
[1]