中国移动企业短信通平台EMPP协议分析

中国移动企信通地址：http://sms.sh.chinamobile.com/qxt/index.jsp

    最近要为手上一个项目设计短信发送，简单分析了一下，最终将使用中国移动企信通作为工具。简单总结一下：

一、选择短信发送方案
1.MAS方式：

    需要采用硬件设备，还要上机架，进行软件安装与配置，非常繁琐，并且成本比较高。
    听某使用mas机的项目反映，延时比较严重，从几分钟，甚至出现过十几分钟的情况。当然可能是设备老旧了。
    放弃！

2.阿里大于
    阿里的东西当然好了，网站上资料很全，但了解同事项目还没有人用过。最主要的一个问题是发送人手机号不能固定吧。
手机端接收显示的号码是106开头的正规号码 显号规则：
a.号码＝通道号＋扩展码；
b.在通道不稳定、网络抖动及机房断电等不可抗拒的因素下，为确保到达率及到达时间，会自动切换通道，通道号会发生变化。
    不知道不知道拆分的短信之间号码变不变，不知道可不可以牺牲达率与时间，保证显示号码不变呢？

3.移动企信通EMPP
    提供了EMPPAPI，并且有相关文档和简单示例。

    最终不知为何选择移动，反正研究起来EMPP。

二、移动EMPP
    有一个企信通平台，企业用户通过分配给自己的账号登录进移动平台，可以发送短信，收到状态，收到回复等功能。自己的应用程序可以使用提供的EmppAPI使用这些功能。
    估计通过API发的短信，在平台里登录也能看到。

    代码在看过阿里的DUBBO后，再看EMPP就简单多了，它也不用NIO。在TCP协议上设计了一个EMPP协议，就简单的用socket编程，主要是把信息对象转成设计好的BYTE[]，发给平台，平台有返回BYTE[]流，再解析出对象来。通常都有消息头与消息体的设计。
   
    1.EmppApi.java与RecvListener.java
    这两个是使用的核心类，EmppApi中一但与远程主机进行连接时，会启动两个线程：

RecvThread：目的是不断接收主机发送过来的信息，生成EMPPObject对象。
buffer=connection.receive(12);
buffer.appendBuffer=connection.receive(length - 12);
EMPPObject.createEMPP(buffer);
EMPPObject实际上有很多具体的类型，包括与主机通讯的各情况，分为emppRequest与emppResponse两大类。

SendActiveThread：目标是不断发送检测对象，保持与主机的tcp连接。
connection.send(emppActiveTest)。

    无论是发送与接收，都是通过socket上的输入输出流来处理的，比较简单。

    2.监听器RecvListener
EmppApi emppApi = new EmppApi();
RecvListener listener = new RecvListener(emppApi);
EMPPConnectResp response = emppApi.connect(host, port, accountId,
password, listener);

     简单的看上面的关系，大BOSS先出生，再生成一个秘书，同时把BOSS传给它，即给BOSS配置了秘书。BOSS干活的时候，把秘书传进去。
     秘书有什么用呢？BOSS不是内部有线程一直在接收吗？接收到了信息，就让秘书去处理。有意思的是OnClosed方法，当收到掉线信息了，那秘书的工作是：新建一个秘书，配置给BOSS来用于重联。

RecvListener listener = new RecvListener(emppApi)
...
emppApi.reConnect(listener);

    另外有一个ByteBuffer类，处理byte[]时很方便。

    3.与协议相关的比较多的细节技术有：
    复制：System.arraycopy.这是一个native方法。
    移位：intBuf[3] = (byte)(data & 255);intBuf[2] = (byte)(data >>> 8 & 255);
    转换：getBytes(编码)。

三、nio与netty
    看到这个EMPPAPI中的技术太旧了，源码是2008年的。简单回顾一下nio吧。
    nio是TCP通信编辑技术io处理的新版本，非阻塞式io，netty是基于nio的一个编程框架。
    老的io是服务器收到一个TCP连接就建一个线程，客户发送完信息就线程等待着读socket上的通道。这两个过程都是阻塞线程。当然客户端发送信息没有任何关系，发送想发就发，想写就写，只是读被阻塞了，它会一直等到数据到来时（或超时）才会返回。
    服务器与客户机等待的时候都是阻塞着的。就是因为阻塞着，怎么办呢？那设计一个统一的线程（公共服务员）去侦听，等到有结果了再通知我，而我不用一直守着，想干嘛就干嘛去。有点象异步通信，有点象回调。

    对于客户端：
      a.先产生一个selector（公共服务员），本通道再服务员处登记一下。
        this.selector = Selector.open(); 
        // 客户端连接服务器,其实方法执行并没有实现连接，需要在listen（）方法中调 
        //用channel.finishConnect();才能完成连接 
        channel.connect(new InetSocketAddress(ip,port)); 
        //将通道管理器和该通道绑定，并为该通道注册SelectionKey.OP_CONNECT事件。 
        channel.register(selector, SelectionKey.OP_CONNECT); 
        channel现在可以做其它事情了...

      b.如果发生了登记的事情
        SocketChannel channel = (SocketChannel) key.channel();
        相关的channel找到了，就可以接着对这个事情做出反馈了。
        channel.write(ByteBuffer.wrap(new String("向服务端发送了一条信息").getBytes()));

      对于服务器：
        serverChannel.register(selector, SelectionKey.OP_ACCEPT);
        上一句也注册了，接下来可以做其它事情了...
        SocketChannel是serverChannel接受好连接产生的通道。是否可以按用户记录在map中，服务器想主动发信息时，可以查询map，找到可用的channel来用？
        ServerSocketChannel/SocketChannel前者用于接收呼入的请求（即第一次握手），而后者负责具体的业务处理（即第一次握手成功后，交由其处理）



四、补充
    又细看了一部分中国移动empp的源码，记录一些知识：
1.协议的设计
  协议包括header与body部分，头部包括三部分，序号号（请求与返回一样），信息总长度，信息类型。总共是12个byte，这个是固定的。body是不固定的。

2.协议的序列化与把序列化
   2.1 发送前要把信息对象转成byte[12+body.length]
    public ByteBuffer getData()
        throws ValueNotSetException
    {
        ByteBuffer bodyBuf = new ByteBuffer();
        bodyBuf.appendBuffer(getBody());
        setCommandLength(bodyBuf.length() + 12);
        ByteBuffer emppBuf = getHeader();
        emppBuf.appendBuffer(bodyBuf);
        return emppBuf;
    }
    其中getBody()中就是把信息的所有属性拼出一个长buffer,比如其中一个：buffer.appendCString(feeTermId, 32);
    之后就是用socket的流写：outputStream.write(data.getBuffer(), 0, data.length());

   2.2 收到后要把byte[]转成对象信息对象
    public EMPPObject receive(long timeout)//对应的方法
    buffer = connection.receive(12);//先取头12个byte
    ByteBuffer bfBody = connection.receive(length - 12);
    buffer.appendBuffer(bfBody);
    return EMPPObject.createEMPP(buffer);
    //根据头部信息new出信息对象后，一个个读取相应长度的byte[]后，设置对象的属性。
    setSrcTermId(buffer.removeCString(21));

    2.3 有个疑问：为何不用java的对象直接写成流的方式呢？？？效率吗？