Hex-Dragon
支持 Scaffolding-MC 联机协议
检查项
- [x] 我已在 Issues 页面 和 常见&难检反馈及问题列表 中搜索，确认了这一提案未被提交过。
- [x] 我已查看 功能投票页面，确认了这一提案未在投票列表中。
- [x] 我知晓还没做的新功能真的太多了，忙不过来，所以新功能提案几乎不会被处理，也不建议再提交新功能提案 qwq……
描述
目前 pcl 是自己的联机协议，导致其他使用 easytier 的联机程序无法互联
https://github.com/Scaffolding-MC/Scaffolding-MC
支持 Scaffolding-MC 协议可实现互联
原因
支持 Scaffolding-MC 协议可实现互联
如 HMCL，未来会有 PCL CE 和 FCL-Team/EnchantNet（？）
先说点题外话。
直至 HMCL 联机公开前，我都完全不知道有这个协议。
更诡异的是，虽然 HMCL 在 文档 里写了 我们欢迎其他启动器接入 Scaffolding 协议实现更完整的互通功能 ，但我在网上搜了半天之后，却发现该协议的文档竟然没有公开？！
由于没有文档和联系渠道，我只能在启动器作者群里求助，希望能够获得协议文档。我在 10 月 4 日、10 月 18 日多次询问，但即使有多位 HMCL 贡献者在群里，我却没有得到哪怕一丁点的回应。 直到最后，半个月过去了，我还是没能拿到文档。那能咋办，总不能一直等吧，只能自己做自己的了。
后来偶然之中，我在 EasyTier 群里讨论技术细节时，管理员告诉我 Scaffolding-MC 协议的作者也在这个群。管理员在群里 @ 他之后，他才当场公开放出了现在的这份文档。
作为一个 HMCL 文档里明文写着 “欢迎接入” 的协议，Scaffolding-MC 协议此前却不提供接入文档，也不公开讨论，这让我相当困惑。
回到技术上。
我个人认为 Scaffolding-MC 协议中的许多必选特性在 PCL 现在的场景下并没有需求。例如，该协议要求客户端/服务端必须实现心跳包验活，但 EasyTier 本身就会发送心跳包，CLI 也会提供延迟数据。 在已经能拿到 Ping 的情况下，再去强制做一套心跳包实现，是没有太大必要的。然而，如果不实现心跳包，就无法完成联机。 我觉得这些内容作为可选特性来实现或许会更好，把这些作为必选实现有的时候增加了无谓的开发和实现难度。
此外，协议中部分复杂的实现也让人望而却步。
例如， c:player_profiles_list 已经使用 JSON 传递数据了，但 c:protocols 却需要使用字节码传递数据，而非更便利的 JSON。
这些复杂化操作使得很多代码都无法重用，必须专门为了这个协议从头搓一套数据包实现。
不过，由于没有任何人让我参与协议的讨论和制定，我的这些改进建议都无处提出。
考虑到现在实现它的难度不低，工作量更是巨大，但对实际联机用户体验却又几乎没有改善，只能说如果有 PR 的话可以去做支持（
作为 Scaffolding 协议的起步参与者，我补充几句。
Scaffolding 最初的设想是在 HMCL 和 PCL CE 把流程跑通以后再对外公开，但出于一些原因（开发时间等），跨启动器对接实际上不是很顺利。这也导致了包括文档公开等在内的一些节点并未按照预期进行。
再说说技术上的。PCL CE 在实现 Scaffolding 协议时也被裸 TCP 连接等困扰了一番，我当时也提到了一些开发难度的问题。但由于陶瓦侧在当时开发进度较快，已经基本完成了相关功能，我们最后还是考虑向他们对齐。
最后，我觉得 HMCL 侧还是欢迎商量的，只是因为一些事情产生了一些误会。PCL CE 在晚些时候也会支持加入由官方版 PCL 创建的房间。目前组内也有成员在开发 .NET Standard 2.0 标准的协议库以方便其他 .NET 启动器接入。PCL CE 及开发组始终不希望与官方社区对立。
由于没有文档和联系渠道，我只能在启动器作者群里求助，希望能够获得协议文档。我在 10 月 4 日、10 月 18 日多次询问，但即使有多位 HMCL 贡献者在群里，我却没有得到哪怕一丁点的回应。
陶瓦联机是由社区开发并贡献给 HMCL 的，启动器群里并没有了解 Scaffolding 协议的 HMCL 贡献者。
我只知道有这样一个东西，但不知道它具体的作用和状态。我以为 PCL CE 那边会把功能贡献回上游，就没吱声（
由于没有文档和联系渠道，我只能在启动器作者群里求助
协议是社区搓的，能在启动器作者群里问到这个协议.... 只能说希望渺茫
而且，鸽秋已经在 PCLC 的群里面甩了好几次文档链接了，CE 很多 Dev （不只是核心开发，甚至不参与开发的也知道了）也知道这份文档，所以下次不如来 PCLC 问问，没准更有效率的说
Glavo 找我聊了聊，感觉是在前期沟通环节上出现了一些问题，然后整件事只有我一个人啥都不知道……但现在再说也于事无补了。
当下的情况是，我个人认为 Scaffolding 引入的一些复杂度是不必要的，它用了比 PCL 协议多数倍的工作量和复杂度去实现相同的功能。但按你们的开发进展，现在又太晚了，很难再去做改变了 :(
如果有 PR 或者第三方工具，还是欢迎的 :)
PCL CE 及开发组始终不希望与官方社区对立。
我的回复里都没有提到 CE 啊，这又是哪来的结论，不要想太多了…… 如果非要说的话，希望可以多交流一下……如果在早期有人能跟我说一声也不至如此 Orz
感觉这完全就是一场大事故... 所有的不正确聚集在了一起导致了最后的草台班子
感觉客观分析一下，首先 HMCL 的信息标注可能不够明确导致了龙猫在错误的地方发起了询问。以至于没有得到想要的结果，最后是催生出 PCL 协议的一大助推点。
而且对于 Scaffolding 协议，其实我认为如果他最终要成为一个跨启动器通用的协议，事后看来，最好的方法应该是在最开始的节点直接公开，通知各大启动器作者知情，并共同在公开平台上协商和优化协议内容，并在最终达成一致后共同实行。
理应是遵循一个公开优先，更多沟通，通知而非等待的原则模式。
不过本身来讲，感觉大家都是受害者，也并没有怪罪任何一方的意思。只能说希望在以后可能的沟通中做得更好吧。
（个人愚见，理性看待）
理应是遵循一个公开优先，更多沟通，通知而非等待的原则模式
我非常同意这个说法 Orz…… （当时 HMCL 文档里写着 “欢迎接入”，但是却不提供接入文档，巨 T M 抽 象）
作为PCL-CE中Scaffolding实现贡献最大的（把底层通讯和交互以及老版本逻辑重构全部写完）我感觉这个协议的问题确实比较多
不过先说协议传播的事。这个协议确实有点不被人所知，既然是要作为一个统一个个启动器之间联机协议的一个标准，那就应该做好一些宣传（例如B站，哪怕是一个专栏也行），至少对于启动器作者是要知道这个东西的存在的。但看现在都情况，确实是龙猫被排除在外，我其实也类似，直到我开始写这个协议的实现的前半小时我才知道这个东西的存在。虽然鸽秋在PCLxC里发过（我不在里面），但毕竟众所周知的龙猫常年不在线，所以也别指望龙猫能看到。与其等着对方找上门还不如先发制人，告知对方有这个东西。
然后是关于协议上我的一些吐槽。
心跳包的问题，对于服务端来说验活完全可以使用EasyTire来做到，十分便捷而且减少代码量（我写服务端处理还要记录一段时间没发心跳包的，好烦人）。玩家列表也是，通过CLI可以直接获取到，即便要做转发服务器的排除处理也要比手写TCP报文舒服
对于传输混用二进制和JSON，这点有点烦。要么全二进制，要么全JSON，就我个人来看混用实在对开发人员不是很友好
我个人认为既然有CLI可以作为联机的时候会话成员信息的获取手段，而且还很方便，这类型的协议就应该作为一个最开始传输基础信息用的工具，而不是架于基础服务提供者之上重复的一个实时信息交换途径。不过这也是我个人的观点，如果有什么特殊的情况必须这样也无妨（
不过虽然文档算是完善，但是没有一个专门用来给开发人员参考的现成的实现。在我看来即便是文档表述的再清楚，也没有代码来的直接，代码是永远也不会骗人的和表述不清那个（特别是那个房间码）。
差不多就是这些吧，有点啰哩啰嗦，就当作是我给CE提交玩Scaffolding的PR后累得要死后的吐槽作品吧
https://github.com/Scaffolding-MC/Scaffolding-MC/issues/6#issuecomment-3472580484
烧师傅的说法.jpg
我正在使用go实现这个协议，计划是首先实现一个无启动器联机中心用于无头客户端，然后进一步实现使scaffolding成为一个启动器无关组件，如果完成，启动器将无需再处理任何网络通讯——乐观的话甚至可以一并解决authlib-injector本地服务器的问题。说到底，为什么一定要启动器来 直接 实现这些东西呢？启动器的理想形态是成为玩mc所需一切操作的入口没错 但是倒也没必要什么事都亲力亲为吧。
回到协议，对于房主（联机中心）而言，心跳包其实根本不需要维护定时器：直接设置读取超时就行了，毕竟我们设置心跳包的目的只是收到一个包，而不是一定要收到心跳包。如果还没完成这部分的可以注意一下。而对于通信部分的其他部分，既然大家都已经实现差不多了，那多说也没用了。
不过协议文档还是可以继续改进的，我说实话，直到目前为止，scaffolding文档还是比较像草稿。文档花了很大的篇幅（其实也不大）讲每个"请求类型"的输入输出格式（实际上我到最后也没看懂vendor是什么意思），但对于最基本的工作流程却只写了几行，这作为一个协议显然是不够的。如果各位认同我的观点的话，可以关注或参与我对scaffolding仓库的fork。
对于pcl，我不认为 短时间内 不急于主动接入scaffolding是一件多么坏的事。毕竟这个协议确实目前为止还不完善。但是长期来讲，只靠hostname来传达联机需要的信息是绝对不够的。就算不使用scaffolding，也需要使用别的东西来传递信息。
如果有需求，可以进一步扩展 PCL 协议，例如使用 hostname 和邀请码传递端口，实现数据交换，和 SCF 类似。
不过我个人对联机功能的期望是……能流畅连上就够了，实现更多的东西感觉没有太大必要性，保持简洁挺好的……（实际上 “能流畅连上” 就已经很难了……）
10月中的时候我也给我自己的启动器 lxdklp/FML 实现完了dart版的协议，glavo发视频hmcl支持联机之前确实一点消息也不知道，不过协议文档其实挺好找到的bing一搜前几个就是，能找到最早在金山文档写的协议规范。说实话我也觉得混用二进制和json很奇怪，而且这个纯hmcl那边在搞，各家启动器目前联机标准也不太一样，不知道啥时候各大启动器各位大佬能讨论出一个统一的联机协议
我正在制作 .NET 版 Scaffolding 协议类库，计划制作完毕后使用该类库向 PCL 添加 Scaffolding 支持。由于我也是后期才知道这个协议（我甚至直接在社区群里），因此之前的宣发问题暂且不谈。从技术层面说，目前来看，这个协议确实有一些硬伤。 前面提到的技术问题不需要再复述一遍，但我在开发过程中遇到了另一个一个较大的问题：并发。 由于 Scaffolding 协议不支持 RequestId 或类似的标识符，因此协议本身不支持并发。当时我因为这个问题折腾了好久，最后只能为收发加一个全局的锁。 解决了这个问题之后我的感受是：这个协议确实不是很完善。我也能理解龙猫为什么不想要支持这协议。
另外，希望未来我给 PCL 提交 Scaffolding 支持 PR 的时候不要被关掉 Orz
