IM 协议选择 - MQTT（mosquitto）

以前大多数im都使用私有协议, 后来发展出开放的xmpp, 使用xml通讯, 不用说消耗网络资源太大了。
我本来想使用protobuf自定义一套私有协议，但想到工作量还是太大，然后发现现在mqtt协议很热门，特别是物联网使用比较多，不过也可以用来做im消息推送服务器。

MQTT开源项目

---

上github搜索golang的mqtt服务器，找到最多star的surgemq，不过一看居然三年没有更新了，作者也不大可能继续维护，在其Issues的一个问题中找到作者的答复说推荐另一个人fork的项目volantmq，不过在网上没有搜索到过于这个项目的文章，所以还是放弃了。
最后发现mosquitto，这是一个eclipse项目组用c语言写的, 更新比较频繁，虽然网上讨论说也有是点问题，但还是暂选择这个项目做为mqtt服务器。
至于客户端，先考虑IOS上的实现，当然是找swift语言编写的，因为实在恶心objc的语法，找到这个CocoaMQTT应该还不错。

安装mosquitto

---

暂时还用不着改mosquitto代码，直接安装可执行程序就行。
mac下:

brew install mosquitto
mosquitto

如果执行mosquitto失败，则
brew info mosquitto
发现可执行文件在usr/local/Cellar/mosquitto/1.4.14_2/sbin/mosquitto

brew安装的mosquitto不支持websocket，要想支持需要自己编译。

安装CocoaMQTT

---

很简单，支持pod，根据CocoaMQTT官方说明直接pod就好，有可能pod下载下来的版本过低，使用pod update后会得到比较新的版本。

MQTT QoS

---

QoS Level 0：至多一次
意思就是给你转发一次就得了，不管你有没收到。
这个我理解是如果接收方离线了就不能收到消息，可以用在音视频聊天请求，因为当接收方离线后就不用收到请求了，就算是接收方在线但是没有收到消息也可以通过发送方超时来重发请求。

image

QoS Level 1：至少一次，有可能重复
也就是说服务器给你重试转发，直到服务器收到客户端的确认消息。
确保至少向客户端发送一次信息，不过也可发送多次；在接收数据包时，需要客户端返回确认消息（ACK 包）。这种方式常用于传递确保交付的信息，但开发人员必须确保其系统可以处理重复的数据包。
这个可以用在普通文本聊天， 接收方离线后，服务器自动缓存消息，等接收方上线时服务器马上把消息推送给他，就算是接收方重复收包也没关系因为可以通过消息里包含的时间来过滤掉。这个级别的消息服务器得注意限制发送方的消息大小和数量，免得服务器内存被爆掉。

image

QoS Level 2：只有一次，确保消息只到达一次
服务器保证你肯定能收到一次，而且只有一次。
这个用在消息重要性比较严格的场合。IM在一般情况下用不着，或者在用户发生金钱消费有关的情况下可以使用？

image

MQTT在IM中的用法

---

可以参考：利用消息队列MQTT，打造一款属于自己的IM社交软件

MQTT的协议格式

---

一文读懂MQTT协议

关于主题Topic

---

主题的设计应该是系统的核心，（可参考MQTT Part 5 主题和最佳实践，顺便可以看看这个blog的MQTT文章。）

每个主题必须包含至少一个字节，并且它还可以包含空格。 另外，主题是区分大小写的，这使得myhome/temperature和MyHome/Temperature是两个单独的主题。除此之外，单独的正斜线也是有效的主题。

主题是utf8字符串，太长的主题会占用较多的网络资源，我想真正项目中对于网络流量比较敏感时应该对主题名字做优化，使用超短的字符，比如每层都只用一个字符来表示。为了提高可读性，平常代码都使用有意义的长字符，内部使用定义message type的方式把每层映射到1个字节，这样保持可读性又大大缩短主题名字的长度，减小占用网络流量。
只取ASCII表128来映射层名，去除33个控制字符和MQTT的保留字符：/, #, +以外，还有92个字符可以使用，可以再去掉一些符号比如空格、正斜杆，星号等，应该还是可以满足需求了，如果不够就再加一个字符呗。
当然对于动态名比如用户ID之类的还是得用原本字符串而不能使用映射。

mosquitto插件扩展

---

mosquitto-auth-plug
mosquitto鉴权插件的开发与说明（一）

参考文章

---

https://www.jianshu.com/nb/13389602