[1]Phoenix库的引入

[2]无中心协议的设计

[3]数据处理接口

[4]其他代码分析

[5]编译和其他

[2]自定义无中心协议的设计

目前没有一个公开的无中心协议,包括我们使用在Phoenixp2p软件里的无中心协议,都是不公开的,为什么呢?因为我们已经提供了组网库,如果再开放无中心组网协议的话,无法避免会有某些人破坏无中心组网的对等规则,例如强行不共享资源,或者只下载不上传,或者采用大流量资源匹配,或者为单一任务申请过多的种子导致其他用户无法申请到种子等等.

我们希望,您抛弃传统的tcp c/s结构协议的框框,在传统c/s结构下,通常次序如下

[1] 客户端 发送指令给服务器端 并等待服务器的反馈或者连接中断

[2] 服务器断接收客户端的指令,判断是否能响应,反馈或者中断连接

在传统的c/s结构中,一般指令都是一一对应的,也就是 每发出一条指令,就必然能得到服务器端的一次响应 [或者连接中断] , 并且每一只能发送一条指令,只要发送成功,那么服务器端就肯定能得到该指令.

使用Phoenix无中心组网库,则完全打破了这个规则,指令可以是可靠指令,也允许是不可靠指令[也就是,以不可靠模式发送,这个指令可能在网络传输阶段就丢了];同样,也没有先后次序,也就是,别的节点可能同时发送多个指令给你,而不是每次发送一条.

下面我们来制定我们自己的无中心指令协议

[1] 握手, 相当于传统FTP协议的登录,Phoenix引擎采用回调函数来处理握手,并且规定,握手字段的最大长度不能超过 1200字节

握手1： HEL0 1 属性参数 *用户名*昵称
握手2： 200 2 属性参数 *用户名*昵称

发送短消息: MSG string

//这里 我们采用的是最简单的握手 保密字是 1 和 2 ， 您应该根据需要加强握手的安全强度 例如要求提供特殊的用户名 hash 等等

握手1 , 是当我们主动发起一个连接,去连接别的节点的时候,我们需要生成的握手字段 , 同理,如果是对方主动发起的连接来连接我们,那么对方也会遵守这个约定.

握手2: 是当我们接到对方的握手1,并确认通过后,返回给对方的握手成功的回答字段,同理,如果是我们主动发起连接,接收到这个回答,并检测参数正确后,我们就可以确定握手通过了.

这里一个必须注意的是,在无中心组网过程中,有可能是你去连接别人,也有可能是别人来连接你,也就是是双向的,你是服务器,也是客户端,必须抛弃传统的客户端-服务器模型.

为了清晰代码,这里我们只实现了一个功能,那就是发送短消息,我们约定,短消息指令,最前面的字符串必须是 MSG , 后面跟空格,然后是短消息的内容,规定,最长的内容不允许超过1300 [这是因为,UDP的MTU大小限制是1400].

到这里,我们的协议就制定完成了,当然,您可以根据需要扩充协议,但是整体的框架我们已经给您完整的构建好了