本篇文章介绍一下业务层的建连流程。

    很多业务有自己的账号系统，比如app登录账号，而p2p中间件也有自己的账号系统(在license文件中的登录账号)，底层实际建立连接用到的是p2p的账号，而从应用层角度来看，应该是应用层两个账号之间创建的连接。这两个账号系统之间是如何关联的，是否必须为每个应用层账号单独分配一个p2p账号呢？

    这里介绍的方案，是p2p账号动态分配和回收方案。通过这种方案，您无需为每个app账号购买一个单独的p2p账号，您购买的p2p账号数量只要超过业务用户最大同时在线数即可，这将极大节约您的购买成本。

     下面具体描述业务层的建连场景：比如业务层有两个登录账号分别为usr1和usr2，p2p系统有两个登录账号分别为peer1和peer2，现在usr1和usr2需要创建连接。当usr1登录业务系统时候，业务系统给usr1动态分配一个p2p登录账号peer1以及对应的登录密码，业务系统记录usr1和peer1对应关系；同理usr2登录到业务系统时候，业务系统给usr2动态分配一个p2p登录账号peer2以及对应的登录密码，业务系统记录好usr2和peer2对应关系。

      当usr1要和usr2通信时候，usr1到业务系统查询usr2对应的登录账号为peer2，然后调用中间件的connect(peer2)创建通信管道；管道创建成功之后，根据需要usr1向usr2发送业务相关的鉴权信息，usr2对信息进行校验，校验通过则允许双工通信，否则直接关闭连接。

      当usr1需要下线时候，向业务系统发出登出消息，然后业务系统可以回收分配给usr1对应的p2p账号peer1，peer1可以再次分配给新登录的用户使用（比如usr3）。

       通过这种动态分配和回收方式，可以让业务账号系统和p2p系统互相解耦，不仅降低了成本，而且十分灵活。流程图如下所示。（流程图省略了usr2登录业务系统的流程，其和usr1登录业务流程相同）

     最后说一下usr1和usr2建连成功之后，usr2如何对usr1进行鉴权，这里给出一种参考方案。usr1向业务系统查询usr2对应得p2p登录账号peer2时候，业务服务器随机生成一个字符串记为A，然后将A和peer2对应得密码拼接一个新得字符串记为B，最后对B进行md5计算生成一个md5值记为C，然后业务服务器将peer2、A、C返回给usr1；当通信连接建立成功之后，usr1将A和C发送给usr2，然后usr2利用相同规则再计算一遍，如果计算出得md5值和C相同则鉴权通过，否则关闭连接。此种方式peer2对应得密码不会在p2p通信管道中传输，是一种比较好的安全得鉴权方式。