现在, 小伙伴觉得隐私是非常重要的一件事情, 谁也不希望裸奔在互联网的汪洋大海之中, 那么如何做到, P2P IM, 无服务器 IM.
从 Android 源代码编译, 发现里面有一个 cpp 的子工程原本想在模拟器上跑一下的, 但是发现里面只有 ARM 的静态链接库
所以只能在真机上跑, 或者去找到这个静态链接库的 x86 版本, 修改一下这里:
就可以在模拟器上跑了, 这个库 opus 是做音频处理的一个开源库, 这里暂时还不知道作者为嘛要装逼弄个 ndk 玩一玩. 不过我想也不妨碍我们求知吧, 先看看他封装了哪些 JNI, 其实挺少了, 也就 4-5 个, 看了下大概就是发送语音的时候需要录音, 嗯~ 继续~
其实, 我看他源码主要是想了解为什么他上线的速度比较慢每次大概需要 20s 左右的时间, 这对用户体验来说无疑是致命一击. 因此, 本文的目的其实是重点来关注下 java 工程, 甚至, 需要在 GitHub 上 clone 一下他的 server 端看看, 才能找到具体原因. 我想大概率是 server 端, 因为我体验 iOS 也是如此之慢的连接速度, 但是连上之后体验还好
判断是否需要登录的逻辑比较简单, 初次登录之后, 在 pref 中写了一个 account 数据, 姑且是标识符把. 然后如果有的化就认为不需要再让用户去登录了, 直接就去主界面了, 当然还有一重判断, 我没框出来, 那就是聊天服务 ChatMainService 是否开启了, 没有开启那是要先开启的.
好吧, 所以, 我们应该需要看看 ChatMainService 为什么便秘了呢??
嗯, 大概想都不用想, 上线逻辑就在这里. 细心的你应该看到, isRunning=ture 表示服务应启动, 但是并没有意味着已经上线, 然后就进去了一个消息循环, 我看到 timer 就想笑了, 因为我之前看到的消息都是推送过来的, 这次换成自己去查, 有点接受不了... 哈哈, 先不管这么多, 继续
嗯, 这个 callback 有点猛, 这么一大堆回调合集啊, 万绿丛中一点红, 我似乎看到了我上线是由谁接待的了.
OK, 我服, 这样一个消息过来, 全部都滚一边, 至于是谁, 你们自己区分去吧. 继续跟踪
好吧, 似乎看到了, 继续下去:
嗯, JNI 了???
ToxLoadJniLibrary.load("tox4j-c");
那么, 跟踪玩之后, 看起来整个过程就是一个 timer 不停的在问 tox4j-c.so 各种状态啊, 然后不停的对各种消息进行分发处理
虽然说上线慢的锅在后端哦 [注意是后端而不是后台, 因为 P2P 网络不存在服务器的] , 但是就这样算了??? 没门, 至少要看看他这个所谓的后端是怎么实现的把.
他后端的项目放在这里 https://github.com/TokTok/c-toxcore
好吧, 我承认不那么容易看懂, 不过初略的看, 确实发现不存在一个中心化的后台 server, 当然然吗中确实有一个文件叫做 TCP_server, 不过, 从注释 Implementation of the TCP relay server part of Tox 可以初略的看出来, 这个是 TCP 中继服务, 从后面我了解到的原理来看, 这个很有可能是用来做 NAT 穿透的.
好吧, 最后了解了一下 p2p https://juejin.im/entry/59c8d3695188256c4b726181 , 所以, 稍微看了下 NAT 穿透, 嗯, 实际上上线缓慢是因为在这些过程中会比较耗时. 但是否还有优化空间, 目前暂不能下结论.
完了之后, 在回过头来看了一下 tox 的核心源码. 发现它是一个分布式的 p2p 网络协议. 准确来说, 它提供了这样的一个网络协议的各种接口, 包含安全加密, DHT 网络, 洋葱路由等核心部件的实现, 以及朋友请求与连接对话, 群聊等模块的实现, 它还包含了音视频库以供用户实现音视频交流的功能.
下图是源码中找到的建立连接的函数滴啊用, 别看就这么简单的设置了一个回调, 其实前面经历过了不少的步骤, 比如, 设置引导节点, 设置 tcp 中继等等
下面是源码文件目录的一览, 可以看到核心部分有加密模块, 分布式网络, 洋葱路由, 以及 TCP 中继 (打通 NAT).
最后奉献一些关于 P2P 的资料
https://bitcoin-on-nodejs.ebookchain.org/3-源码解读/3-一个精巧的p2p网络实现.html
来源: https://www.qcloud.com/developer/article/1456513