mqtt底层是socket(mqtt底层协议)

启动方式: 解压缩,进入apache-activemq-5.9.0-binapache-activemq-5.9.0bin,双击activemq.bat,即可启动activeMQ服务启动之后: android客户端推送采用mqtt(paho-mqtt-client-1.0.1.jar),
做法是通过socket.io做中转，websocket连接到socekt.io上，后台nodejs再连接到mqtt server上。

1.Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。 2.MQTT协议是应用层协议不依赖长连接，适合弱网络。通过topic缓存信息。符合物联网设备的使用场景。因为通过topic缓存信息，因此可以实现通过topic与多个端的一对多连接，而不是设备与设备的多对多连接，节省了能耗及带宽。MQTT的心跳，及非信息的报文，较Websocket更少，更节省带宽及能耗。更适用于物理网的多种网络协议。3.WebSocket和Http一样在应用层,提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。Socket 连接,至少需要一对套接字，分为 clientSocket，serverSocket 连接分为3个步骤:(1) 服务器监听:服务器并不定位具体客户端的套接字，而是时刻处于监听状态；(2) 客户端请求:客户端的套接字要描述它要连接的服务器的套接字，提供地址和端口号，然后向服务器套接字提出连接请求；(3) 连接确认:当服务器套接字收到客户端套接字发来的请求后，就响应客户端套接字的请求,并建立一个新的线程,把服务器端的套接字的描述发给客户端。一旦客户端确认了此描述，就正式建立连接。而服务器套接字继续处于监听状态，继续接收其他客户端套接字的连接请求.Socket为长连接：通常情况下Socket 连接就是 TCP 连接，因此 Socket 连接一旦建立,通讯双方开始互发数据内容，直到双方断开连接。在实际应用中，由于网络节点过多，在传输过程中，会被节点断开连接，因此要通过轮询高速网络，该节点处于活跃状态。很多情况下，都是需要服务器端向客户端主动推送数据，保持客户端与服务端的实时同步。若双方是 Socket 连接，可以由服务器直接向客户端发送数据。若双方是 HTTP 连接，则服务器需要等客户端发送请求后，才能将数据回传给客户端。因此，客户端定时向服务器端发送请求，不仅可以保持在线，同时也询问服务器是否有新数据，如果有就将数据传给客户端。MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如：①网络代价昂贵，带宽低、不可靠。②在嵌入设备中运行，处理器和内存资源有限。该协议的特点有：①使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。②对负载内容屏蔽的消息传输。③使用 TCP/IP 提供网络连接。④有三种消息发布服务质量：⑤"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。⑥"至少一次"，确保消息到达，但消息重复可能会发生。⑦"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。⑧小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。实现MQTT协议需要客户端和服务器端通讯完成，在通讯过程中，MQTT协议中有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。有三种消息发布服务质量：“至多一次”，消息发布完全依赖底层TCP/IP网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。这一种方式主要普通APP的推送，倘若你的智能设备在消息推送时未联网，推送过去没收到，再次联网也就收不到了。qos=0“至少一次”，确保消息到达，但消息重复可能会发生。qos=1“只有一次”，确保消息到达一次。在一些要求比较严格的计费系统中，可以使用此级别。在计费系统中，消息重复或丢失会导致不正确的结果。这种最高质量的消息发布服务还可以用于即时通讯类的APP的推送，确保用户收到且只会收到一次。qos=2Topic，可以理解为消息的类型，订阅者订阅（Subscribe）后，就会收到该主题的消息内容（payload）；payload，可以理解为消息的内容，是指订阅者具体要使用的内容。在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、可变头（Variable header）、消息体（payload）三部分构成。MQTT数据包结构如下：固定头（Fixed header）。存在于所有MQTT数据包中，表示数据包类型及数据包的分组类标识。可变头（Variable header）。存在于部分MQTT数据包中，数据包类型决定了可变头是否存在及其具体内容。消息体（Payload）。存在于部分MQTT数据包中，表示客户端收到的具体内容。 WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。由此可知两者的应用场景不一样：MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。

时间：2018-07-26Q: 什么是网络连接？A:网络连接是传输层定义的概念，在传输层以下只存在网络数据包的相互交换。所谓连接，其实也不是在网络上有一条真实存在的数据通道。只要通信双方在一段时间内持续保持数据包交换，就可以视为双方建立的连接并没有断开。连接的建立是依托于TCP协议的三次握手，一旦连接已经建立完毕，通信双方就可以复用这条虚拟通道进行数据交换。如果连接保持长时间工作一直没有被中断，那么这样的TCP连接就俗称为长连接。Message Queue Telemetry Transport ，中文直译：消息队列遥测传输协议。在MQTT协议被设计出来的年代，还没有物联网这么时髦的词汇，当年叫做遥测设备。MQTT协议真正开始声名鹊起的原因，是其正好恰恰踩中移动互联网发展的节拍，为消息推送场景提供了一个既简便又具有良好扩展性的现成解决方案。http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html可以看出，MQTT对消息头的规定十分精简，固定头部占用空间大小仅为1个字节，一个最小的报文占用的空间也只有两个字节（带一字节的长度标识位）。这也是MQTT协议针对不稳定及带宽低下的网络环境做出的特定设计 - - - -尽可能地节省一切不必要的网络开销。Q：为什么MQTT协议需要心跳报文(PINGREQ, PINGRESP)来维护连接状态，只监控该TCP的连接状态是否可以实现目的？A:TCP数据传输默认的超时时间过长，不符合应用层上细粒度的要求。TCP数据传输超时的情况可分成三种： 服务端断开 、 客户端断开 、 中间网络断开 。在前两种场景下，若断开操作是一方主动发起的，即表示为TCP连接正常结束，双方走四次挥手流程；若程序异常结束，则会触发被动断开事件，通信另一方也能立刻感知到本次连接所打开的 Socket 出现中断异常。唯独中间网络的状态是通信双方不能掌握的。在Linux系统下，TCP的连接超时由内核参数来控制，如果通信中的一方没有得到及时回复，默认会主动再尝试6次。如果还没有得到及时回应，那么其才会认定本次数据超时。连带首次发包与六次重试，Linux系统下这7次发包的超时时间分别为2的0次方至2的6次方，即1秒、2秒、4秒、8秒、16秒、32秒、64秒，一共127秒。MQTT协议认为如此长的超时时间对应用层而言粒度太大，因此其在应用层上还单独设计属于自身的心跳响应控制。常见的MQTT连接超时多被设定为 60秒 。扩展知识- TCP的KeepAlive机制： http://hengyunabc.github.io/why-we-need-heartbeat/由通信中的报文标识符(Packet Identifier )传达。Q：仅Publish与Pubrec能保证消息只被投递一次吗？A：业务上可以实现，但MQTT协议并没有如此设计，原因如下：每个消息都会拥有属于自己的报文标识符，但如果需要两次数据交换就实现消息仅只收到一次，就需要通信双方记录下每次使用的报文标识符，并且在处理每一条消息时都需要去重处理，以防消息被重复消费。但MQTT协议最初被设计的工作对象是轻量级物联设备，为此在协议的设计中报文标识符被约定为可重用，以减少对设备性能的消耗，换回的代价不得不使用四次网络数据交换，才能确保消息正好被消费一次。Q：两个不同客户端在发布与订阅同一Topic下的消息时，都可以提出通信Qos要求，此时以哪项为基准？A：伪命题，故意在分享时埋下坑，等人来踩。两个不同客户端的通信是需要 Broker 进行中转，而不是直连。因此，通信中存在两个不同的会话，双方的Qos要求仅仅作用于它们与 Broker 之间的会话，最终的Qos基准只会向最低要求方看齐。例：遗嘱消息的正确使用方式可参考此篇文章： https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament虽然可以借助Retain Message实现绑定一条消息至某个Topic，以达到消息的暂时保留目的。但首先Retain Message并不是为存储场景而设计的，再次MQTT协议并没有对消息的持久化作出规定，也就是说Broker重启后，现有保留消息也将丢失。Q：两种特殊消息的使用场景？A：遗嘱消息，多用于客户端间获取互相之间异常断线的消息通知；保留消息，可保存最近一条广播通知，多用于公告栏信息的发布。Eclipse Mosquitto ：MQTT协议的最小集实现有 EMQ ,HiveMQ ,RabbitMQ MQTT Adapter 等。Qos=2 消息保障的网络I/O次数过多，如果不是必需，尽少在程序里使用此类消息。毕竟当初其设计的目的是为了减少设备的性能占用，但若应用场景并不是物联网，而是用于手机、电脑或浏览器端等现在已不缺性能的设备上，最好在报文体中，使用UUID生成全局唯一的消息ID，然后自行在业务解析中判断此报文是否被消费过。或者，业务方在处理消息时保证其被消费的幂等性，也可消除重复消息对系统带来的影响。正如MQTT协议并没有依赖TCP连接状态，自己在应用层协议上实现心跳报文来控制连接状态，业务方作为MQTT协议的使用者，也不要完全依赖协议的工作状态，而是依托MQTT协议建立属于业务本身的信息汇报机制，以加强系统的稳健性。Retain Message 可视为客户端主动拉取的行为。如果业务系统采用HTTP+MQTT双协议描述业务过程，主动拉取的操作也可使用HTTP请求替代。作为一个长连接型的应用，上线前需要根据业务量级，评估对操作系统端口数与文件描述符的占用要求，以防服务器资源被打满。在服务端的配置文件和客户端的连接参数中，都拥有 max_inflight_messages 此项配置，来维护 Qos=1 or 2 消息是否被成功消费的状态。MQTT 最初被设计为物联网级的通信协议，因此此参数的默认配额较小（大多数情况下被限制到10至20）。但如果将MQTT协议应用至手机、PC或Web端的推送场景时，硬件性能已不在是瓶颈，在实际使用中推荐把此参数调大。Mosquitto提供Bridge功能，需要我们自己配置。Bridge 意为桥接，当我们把两台Broker桥接在一起时，只需要修改一台Broker的配置，填上另一台Broker的运行地址。前一台Broker将作为客户端发布与订阅后一台Broker的所有Topic，实现消息互通的目的。桥接带来的问题有以下几点：我的建议：Websockets协议被设计的目的是为浏览器提供一个全双工的通信协议，方便实现消息推送功能。在Websockets协议被设计出来前，受限于HTTP协议的一问一答模型，消息的推送只能靠轮询来实现，在资源消耗与时效性保障上，均难以达到令人满意的效果。Websockets协议复用了HTTP协议的头部信息，告知浏览器接下来的操作将触发协议升级，然后通信双方继续复用HTTP的Header，但报文内容已转变为双方均接受的新协议的格式。Websockets协议改进了网页浏览中的消息推送的方式，因此被广泛应用在聊天、支付通知等实时性要求比较高的场合下。MQTT协议重点在于消息队列的实现，其对消息投递的方式作出约定，并提供一些额外的通信保障。MQTT可采取原生的TCP实现，也有基于Websockets的实现版本。当然后者在网络字节的利用率上，不如前者那么精简。但浏览器端无法直接使用TCP协议，所以就只能基于Websockets协议开发。不过基于Websockets的应用也有方便之处：一是证书不需要额外配置，直接与网站共用一套基础设施；二是可使用Nginx等工具管理流量，与普通HTTP流量可共用一套配置方法。MQTT非常适合入门，原因如下：实际的应用场景远比理想中的复杂，无法一招走遍天下，必须做好取舍。MQTT协议在这方面做得很优秀，以后工作中可以作为参考，设计好自己负责的业务系统。

MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议。 而WebSocket则是浏览器与服务器全双工通信（MQTTMessage Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。 WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duplex)。一开始的握手需要借助HTTP请求完成。
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是轻量级基于代理的发布/订阅的消息传输协议，设计思想是开放、简单、轻量、易于实现。这些特点使它适用于受限环境。例如： ①网络代价昂贵，带宽低、不可靠。②在嵌入设备中运行，处理器和内存资源有限。该协议的特点有：①使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。②对负载内容屏蔽的消息传输。③使用 TCP/IP 提供网络连接。④有三种消息发布服务质量：⑤"至多一次"，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。⑥"至少一次"，确保消息到达，但消息重复可能会发生。⑦"只有一次"，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。⑧小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量。⑨使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制。WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。由此可知两者的应用场景不一样：MQTT是为了物联网场景设计的基于TCP的Pub/Sub协议，有许多为物联网优化的特性，比如适应不同网络的QoS、层级主题、遗言等等。WebSocket是为了HTML5应用方便与服务器双向通讯而设计的协议，HTTP握手然后转TCP协议，用于取代之前的Server Push、Comet、长轮询等老旧实现。 两者之所有有交集，是因为一个应用场景：如何通过HTML5应用来作为MQTT的客户端，以便接受设备消息或者向设备发送信息，那么MQTT over WebSocket自然成了最合理的途径了。

socket编程是吧？ 我有。。。 demo也有。。
package com.zgnet.billing.service; import org.json.JSONObject;import android.annotation.SuppressLint;import android.app.AlarmManager;import android.app.NotificationManager;import android.app.PendingIntent;import android.app.Service;import android.content.BroadcastReceiver;import android.content.Context;import android.content.Intent;import android.content.IntentFilter;import android.content.SharedPreferences;import android.media.MediaPlayer;import android.net.ConnectivityManager;import android.net.NetworkInfo;import android.os.IBinder;import android.os.StrictMode;import android.util.Log;import com.ibm.mqtt.IMqttClient;import com.ibm.mqtt.MqttClient;import com.ibm.mqtt.MqttException;import com.ibm.mqtt.MqttPersistence;import com.ibm.mqtt.MqttPersistenceException;import com.ibm.mqtt.MqttSimpleCallback;import com.zgnet.billing.utils.WebServiceConfig;/** PushService that does all of the work.* Most of the logic is borrowed from KeepAliveService.*http://code.google.com/p/android-random/source/browse/trunk/TestKeepAlive/src/org/devtcg/demo/keepalive/KeepAliveService.java?r=219*/public class PushService extends Service {// this is the log tagpublic static final String TAG = "ZgnetPushService";// the IP address, where your MQTT broker is running.服务器ipprivate static final String MQTT_HOST = "192.168.10.4";// private static final String MQTT_HOST = "10.10.15.113";// the port at which the broker is running. 服务器端口private static int MQTT_BROKER_PORT_NUM = 1883;// Let's not use the MQTT persistence.private static MqttPersistence MQTT_PERSISTENCE = null;// We don't need to remember any state between the connections, so we use a// clean start.private static boolean MQTT_CLEAN_START = true;// Let's set the internal keep alive for MQTT to 15 mins. I haven't tested// this value much. It could probably be increased.private static short MQTT_KEEP_ALIVE = 60 * 15;// Set quality of services to 0 (at most once delivery), since we don't want// push notifications// arrive more than once. However, this means that some messages might get// lost (delivery is not guaranteed)private static int[] MQTT_QUALITIES_OF_SERVICE = { 0 };private static int MQTT_QUALITY_OF_SERVICE = 0;// The broker should not retain any messages.private static boolean MQTT_RETAINED_PUBLISH = false;// MQTT client ID, which is given the broker. In this example, I also use// this for the topic header.// You can use this to run push notifications for multiple apps with one// MQTT broker.public static String MQTT_CLIENT_ID = "zgnet";// These are the actions for the service (name are descriptive enough)private static final String ACTION_START = MQTT_CLIENT_ID + ".START";private static final String ACTION_STOP = MQTT_CLIENT_ID + ".STOP";private static final String ACTION_KEEPALIVE = MQTT_CLIENT_ID+ ".KEEP_ALIVE";private static final String ACTION_RECONNECT = MQTT_CLIENT_ID+ ".RECONNECT";// Connection log for the push service. Good for debugging.// private ConnectionLog mLog;// Connectivity manager to determining, when the phone loses connectionprivate ConnectivityManager mConnMan;// Notification manager to displaying arrived push notifications@SuppressWarnings("unused")private NotificationManager mNotifMan;// Whether or not the service has been started.private boolean mStarted;// This the application level keep-alive interval, that is used by the// AlarmManager// to keep the connection active, even when the device goes to sleep.private static final long KEEP_ALIVE_INTERVAL = 1000 * 60 * 28;// Retry intervals, when the connection is lost.private static final long INITIAL_RETRY_INTERVAL = 1000 * 10;private static final long MAXIMUM_RETRY_INTERVAL = 1000 * 60 * 30;// Preferences instanceprivate SharedPreferences mPrefs;// We store in the preferences, whether or not the service has been startedpublic static final String PREF_STARTED = "isStarted";// We also store the deviceID (target)public static final String PREF_DEVICE_ID = "deviceID";// We store the last retry intervalpublic static final String PREF_RETRY = "retryInterval";// Notification titlepublic static String NOTIF_TITLE = "Tokudu";// Notification id@SuppressWarnings("unused")private static final int NOTIF_CONNECTED = 0;// This is the instance of an MQTT connection.private MQTTConnection mConnection;private long mStartTime;JSONObject js = null;@SuppressWarnings("unused")private MediaPlayer mp;// Static method to start the servicepublic static void actionStart(Context ctx) {Intent i = new Intent(ctx, PushService.class);i.setAction(ACTION_START);ctx.startService(i);}// Static method to stop the servicepublic static void actionStop(Context ctx) {Intent i = new Intent(ctx, PushService.class);i.setAction(ACTION_STOP);ctx.startService(i);}// Static method to send a keep alive messagepublic static void actionPing(Context ctx) {Intent i = new Intent(ctx, PushService.class);i.setAction(ACTION_KEEPALIVE);ctx.startService(i);}@Overridepublic void onCreate() {super.onCreate();log("Creating service");mStartTime = System.currentTimeMillis();// try {// mLog = new ConnectionLog();// Log.i(TAG, "Opened log at " + mLog.getPath());// } catch (IOException e) {// Log.e(TAG, "Failed to open log", e);// }// Get instances of preferences, connectivity manager and notification// managermPrefs = getSharedPreferences(TAG, MODE_PRIVATE);mConnMan = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);mNotifMan = (NotificationManager) getSystemService(NOTIFICATION_SERVICE);/** If our process was reaped by the system for any reason we need to* restore our state with merely a call to onCreate. We record the last* "started" value and restore it here if necessary.*/handleCrashedService();}// This method does any necessary clean-up need in case the server has been// destroyed by the system// and then restartedprivate void handleCrashedService() {if (wasStarted() == true) {log("Handling crashed service...");// stop the keep alivesstopKeepAlives();// Do a clean startstart();}}@Overridepublic void onDestroy() {log("Service destroyed (started=" + mStarted + ")");// Stop the services, if it has been startedif (mStarted == true) {stop();}// try {// if (mLog != null)// mLog.close();// } catch (IOException e) {}}@SuppressWarnings("deprecation")@Overridepublic void onStart(Intent intent, int startId) {super.onStart(intent, startId);log("Service started with intent=" + intent);// Do an appropriate action based on the intent.if (intent.getAction().equals(ACTION_STOP) == true) {stop();stopSelf();} else if (intent.getAction().equals(ACTION_START) == true) {start();} else if (intent.getAction().equals(ACTION_KEEPALIVE) == true) {keepAlive();} else if (intent.getAction().equals(ACTION_RECONNECT) == true) {if (isNetworkAvailable()) {reconnectIfNecessary();}}}@Overridepublic IBinder onBind(Intent intent) {return null;}// log helper functionprivate void log(String message) {System.out.println("----------------------------" + message);}// Reads whether or not the service has been started from the preferencesprivate boolean wasStarted() {return mPrefs.getBoolean(PREF_STARTED, false);}// Sets whether or not the services has been started in the preferences.private void setStarted(boolean started) {mPrefs.edit().putBoolean(PREF_STARTED, started).commit();mStarted = started;}private synchronized void start() {log("Starting service...");// Do nothing, if the service is already running.if (mStarted == true) {Log.w(TAG, "Attempt to start connection that is already active");return;}// Establish an MQTT connectionconnect();// Register a connectivity listenerregisterReceiver(mConnectivityChanged, new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION));}private synchronized void stop() {// Do nothing, if the service is not running.if (mStarted == false) {Log.w(TAG, "Attempt to stop connection not active.");return;}// Save stopped state in the preferencessetStarted(false);// Remove the connectivity receiverunregisterReceiver(mConnectivityChanged);// Any existing reconnect timers should be removed, since we explicitly// stopping the service.cancelReconnect();// Destroy the MQTT connection if there is oneif (mConnection != null) {mConnection.disconnect();mConnection = null;}}//private synchronized void connect() {log("Connecting...");// fetch the device ID from the preferences.String deviceID = mPrefs.getString(PREF_DEVICE_ID, null);// Create a new connection only if the device id is not NULLif (deviceID == null) {log("Device ID not found.");} else {try {mConnection = new MQTTConnection(MQTT_HOST,new String[] { "billing"+ WebServiceConfig.DEPARTMENTID });} catch (MqttException e) {// Schedule a reconnect, if we failed to connectlog("MqttException: "+ (e.getMessage() != null ? e.getMessage() : "NULL"));if (isNetworkAvailable()) {scheduleReconnect(mStartTime);}}setStarted(true);}}private synchronized void keepAlive() {try {// Send a keep alive, if there is a connection.if (mStarted == true && mConnection != null) {mConnection.sendKeepAlive();}} catch (MqttException e) {mConnection.disconnect();mConnection = null;cancelReconnect();}}// Schedule application level keep-alives using the AlarmManagerprivate void startKeepAlives() {Intent i = new Intent();i.setClass(this, PushService.class);i.setAction(ACTION_KEEPALIVE);PendingIntent pi = PendingIntent.getService(this, 0, i, 0);AlarmManager alarmMgr = (AlarmManager) getSystemService(ALARM_SERVICE);alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP,System.currentTimeMillis() + KEEP_ALIVE_INTERVAL,KEEP_ALIVE_INTERVAL, pi);} // Remove all scheduled keep alives
看起来很麻烦的样子。我用xmpp貌似没这么麻烦。有个openfire已经帮我们实现。