基于 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]