MENU

【代码札记】从零开始的点对点聊天系统 P0

November 24, 2022 • 瞎折腾

本篇为该系列的介绍。该系列将讲述我为Minecraft构造一个点对点聊天系统的过程。

起因

事情的起因是微软和Mojang决定在Minecraft 1.19中引入消息签名和举报封禁系统。关于这个系统的争论这里就不多说了,这里我推荐大家观看Aizistral的Youtube频道,他制作了一系列视频讲述了这个机制的原理和潜在的漏洞。总地来说,微软和Mojang的这一系列操作,从技术上讲并不安全(可以利用诸如gaslighting等漏洞捏造举报记录并陷害别人),从道理上来讲也不合适(由此引发的封禁会导致正版玩家在封禁期间无法在任何版本上加入多人游玩,因为Mojang的登录认证服务器会拒绝处理你的请求,而这会影响到所有版本)。而Mod社区作为反击,出现了诸如NoChatReports等模组来禁用消息签名,进而阻止其他玩家举报使用者。

而我已经想给Minecraft写mod很久了,但是苦于没有想法,也一直没有入门的动力。最近在研究I2P,全称The Invisible Internet Project,翻译过来就是隐匿网。它的功能比Tor还要厉害。Tor提供了隐匿互联网踪迹的功能,同时还提供了所谓的暗网(基于电路交换);而I2P则压根不考虑隐匿互联网行踪,它直接搞了个Internet over Internet,它所使用的协议比Tor更加具有抵抗力。听说这个项目目前是由俄罗斯人领导开发的,只能说,俄罗斯还是高手在民间。因为I2P也是Java写的,我也刚好写Java,所以就想着能不能给这个项目贡献一些自己的力量,但发现自己的水平还是不太行,只能围绕着I2P做一些外围的开发。

于是我便有了一个想法:如果我们劫持Minecraft的聊天系统,岂不是从根本上解决问题?在原版Minecraft中,发送聊天消息主要是这个流程:

聊天相关的UI -> 处理消息(签名、加入数据包队列) -> 发送给服务器

服务器收到玩家的消息之后,服务器首先检查消息签名,然后将用户信息与签名的消息一起转发给每一个人:

收到服务器转发的消息 -> 验证签名 -> 放入聊天栏

如果我们的模组能够劫持这个过程,在处理消息的时候将消息交给模组处理,从而避免将消息签名、发送给服务器;同时模组将接收到的消息直接放入聊天栏,这样不就完全绕开了他们的消息签名那一套?之后无论微软和Mojang怎么改,只要他们还在游戏内提供聊天功能,这个办法就永远不会过时。

EULA?狗屁!

结果

为什么没有经过呢?因为经过是本系列后续文章的事儿。

既然如此,说干就干。经过一番折腾,最终得到了两个Repo:

从结果来说,这是我第一次为Minecraft写mod,也是第一次设计点对点系统。要我自己说,我觉得还不错;但是客观上讲,其实还是差远了。作为Mod来说,这个mod缺乏用户友好的教程、文档和游戏内配置等;作为一个点对点系统来说,好多功能和细节还有待打磨,同时在设计这个系统的时候,对于防范攻击并没有太多的考量与设计,真要是用起来的话,还得重新审视一下这方面的问题。

不过从过程来说,我确实学到了不少东西。我的毕业设计是做了一个可以集群部署的系统,集群内同步的方式依赖于第三方服务(例如可集群部署的数据库和Etcd),而在设计模式上也是C/S模式,具有明显的主从关系。但是点对点系统不太一样,当然也可以按照主从模式来设计——最开始我就是这样写的:每个节点有一个服务端和客户端,节点之间必须有两条TCP连接才可以通信:服务端的入站用来接收消息,客户端的出站用来发送消息。我当然知道TCP可以全双工,但是那样的话就要考虑复用和同步控制的问题。总之,随着项目的进行,我逐渐累积了一些点对点系统的经验,最终当然还是设计成了单个TCP连接。也正是出于此,我想将我在其中学到的一些经验整理出来与大家分享,因此也便有了这个系列。

考虑到本篇只是起到一个开篇、引路的做用,因此就不多啰嗦了。我们下一篇见,大家敬请期待。


知识共享许可协议
【代码札记】从零开始的点对点聊天系统 P0天空 Blond 采用 知识共享 署名 - 非商业性使用 - 相同方式共享 4.0 国际 许可协议进行许可。
本许可协议授权之外的使用权限可以从 https://skyblond.info/about.html 处获得。

Archives QR Code
QR Code for this page
Tipping QR Code