关于局域网收取选手文件的讨论

[Dust1404]

#66
这里开个讨论，对一下功能和技术选择，确定下来之后我大概 9 月份开始开发。

功能上

需要开发一个 LemonLime-Client，可以输入 姓名 和 收取目录，当有收取请求的时候，可以选择允许或拒绝（防止机房内有人冒充老师收取）。

在 LemonLime 本体上添加：搜索局域网中所有选手，收取局域网中所有选手的文件。收取时，新建以选手姓名命名的文件夹，文件夹下的结构同选手本地选择的收取目录。可以限制最大收取文件大小和最大文件夹递归深度，以及后缀名等等（待讨论）。

技术选择

机器间通信：选择 gRPC。主要是提高开发效率以及性能的考虑，Client 端的开发语言可以不只限于 Qt。提供如下接口（暂定）

RegisterContestant(userName : string) // 向本体注册本机选手
UnregisterContestant() // 考虑是否需要
MakeDir(path : string) // 向本体告知文件夹结构
SendFile(path : string, content : byte[]) // 向本体发送文件
// IP 用于区分选手

具体通信过程：本体 UDP 在局域网内广播，Client 收到 UDP 广播后，调用 RegisterContestant 向本体注册，然后若 UDP 指定发送文件（区分搜索选手和收取选手文件两个功能。这里因为之前的注册过程已经获取到了所有 Client 的 IP，所以可以对点通信再发送收取文件的请求，需要再讨论一下，每个 Client 可以再成为一个 gRPC 的 Server，提供收取文件的接口），则遍历文件夹使用 MakeDir 和 SendFile。本体需要维护 IP 到 userName 的映射。

其他问题：关于端口的选择，需要确定两个端口，分别是 UDP 和 gRPC 的。

Client 端 GUI 技术选择

考虑到 Client 端实现的功能较少，暂时有三个待选项

• Webview，用 Web 开发那一套理论，缺点是对老系统（比如 win7）的兼容性（不过好像本体已经放弃兼容了）
• Qt，接着用 C++
• Golang + Flutter，是否太重量级了

[CoelacanthusHex]

#66 这里开个讨论，对一下功能和技术选择，确定下来之后我大概 9 月份开始开发。

功能上

需要开发一个 LemonLime-Client，可以输入 姓名 和 收取目录，当有收取请求的时候，可以选择允许或拒绝（防止机房内有人冒充老师收取）。

在 LemonLime 本体上添加：搜索局域网中所有选手，收取局域网中所有选手的文件。收取时，新建以选手姓名命名的文件夹，文件夹下的结构同选手本地选择的收取目录。可以限制最大收取文件大小和最大文件夹递归深度，以及后缀名等等（待讨论）。

技术选择

机器间通信：选择 gRPC。主要是提高开发效率以及性能的考虑，Client 端的开发语言可以不只限于 Qt。提供如下接口（暂定）

其实有一种方案是我们直接起一个 HTTP Server，Server 地址通过 Bonjour 告知客户端（或者不采用 Bonjour 的话可以采用其他方案设置，最简单粗暴的方案用户手动填写 IP，复杂一点的是 UDP 广播），Register 直接把信息 POST 请求给 SERVER/register，上传文件往 SERVER/${contestName}/${problemName}/${fileName} 使用 POST 请求上传文件，非常简单粗暴，编程也没有啥需要新学的技术，也不需要引入 gRPC 这个经常 break ABI 的依赖。

RegisterContestant(userName : string) // 向本体注册本机选手
UnregisterContestant() // 考虑是否需要

出现问题的话不一定有机会执行 Unregister，考虑到内网使用，可以考虑使用心跳包方案作为替代。

MakeDir(path : string) // 向本体告知文件夹结构

目录结构由服务端定义是一种更符合 OI 习惯的方案

SendFile(path : string, content : byte[]) // 向本体发送文件
// IP 用于区分选手

具体通信过程：本体 UDP 在局域网内广播，Client 收到 UDP 广播后，调用 `RegisterContestant` 向本体注册，然后若 UDP 指定发送文件（区分搜索选手和收取选手文件两个功能。这里因为之前的注册过程已经获取到了所有 Client 的 IP，所以可以对点通信再发送收取文件的请求，需要再讨论一下，每个 Client 可以再成为一个 gRPC 的 Server，提供收取文件的接口），则遍历文件夹使用 `MakeDir` 和 `SendFile`。本体需要维护 IP 到 userName 的映射。

服务发现可以直接复用已有的公开技术栈，使用 mDNS+DNS-SD (Bonjour)，服务端注册 Bonjour 服务，客户端在局域网内查询服务。如果该校机房设置了计算机名，mDNS 也可以更简单地完成名称到 IP 的映射。

其他问题：关于端口的选择，需要确定两个端口，分别是 UDP 和 gRPC 的。

如果使用 Bonjour 则不需要提前约定 gRPC 端口， Bonjour 注册服务时可以现场填写，提供更大的灵活性；使用 Bonjour 的话则使用公开协议已有的接口，不需要自己定义一个单独的 UDP 广播接口，减少需要的防火墙调整。

Client 端 GUI 技术选择

考虑到 Client 端实现的功能较少，暂时有三个待选项

* Webview，用 Web 开发那一套理论，缺点是对老系统（比如 win7）的兼容性（不过好像本体已经放弃兼容了）

不好说，有可能会发生老师/学长用笔记本电脑在机房收取机房电脑上的代码的情况。但是个人觉得用 Webview 并不是很适合这个场景。

* Qt，接着用 C++

沿用本体技术栈可以降低用户的心智负担。

* Golang + Flutter，是否太重量级了

Flutter 中文和字体支持一直很烂。

[Dust1404]

#66 这里开个讨论，对一下功能和技术选择，确定下来之后我大概 9 月份开始开发。

功能上

需要开发一个 LemonLime-Client，可以输入 姓名 和 收取目录，当有收取请求的时候，可以选择允许或拒绝（防止机房内有人冒充老师收取）。
在 LemonLime 本体上添加：搜索局域网中所有选手，收取局域网中所有选手的文件。收取时，新建以选手姓名命名的文件夹，文件夹下的结构同选手本地选择的收取目录。可以限制最大收取文件大小和最大文件夹递归深度，以及后缀名等等（待讨论）。

技术选择

机器间通信：选择 gRPC。主要是提高开发效率以及性能的考虑，Client 端的开发语言可以不只限于 Qt。提供如下接口（暂定）

其实有一种方案是我们直接起一个 HTTP Server，Server 地址通过 Bonjour 告知客户端（或者不采用 Bonjour 的话可以采用其他方案设置，最简单粗暴的方案用户手动填写 IP，复杂一点的是 UDP 广播），Register 直接把信息 POST 请求给 SERVER/register，上传文件往 SERVER/${contestName}/${problemName}/${fileName} 使用 POST 请求上传文件，非常简单粗暴，编程也没有啥需要新学的技术，也不需要引入 gRPC 这个经常 break ABI 的依赖。

引入 gRPC 主要是有一些开发效率以及安全上的考虑（不过局域网也不太需要考虑安全），没了解过经常 break ABI 的事，那就不考虑 gRPC 了。

RegisterContestant(userName : string) // 向本体注册本机选手
UnregisterContestant() // 考虑是否需要

出现问题的话不一定有机会执行 Unregister，考虑到内网使用，可以考虑使用心跳包方案作为替代。

这里原来考虑 Unregister 其实用处不大，这里写了只是保持接口完整性。心跳包我觉得用处不大，因为不需要持续维护每个选手的状态，选手状态只有在服务端发出请求的时候才需要知道。

MakeDir(path : string) // 向本体告知文件夹结构

目录结构由服务端定义是一种更符合 OI 习惯的方案

这里是考虑到可能有不同的文件夹结构，例如有子文件夹的选项，如果由服务端定义可能直接 GET 会更好。
以及我们机房曾经干过用 Cena 收其他文件的事情，所以这里的意思是选手直接把整个文件夹上传，不考虑比赛的文件结构。

SendFile(path : string, content : byte[]) // 向本体发送文件
// IP 用于区分选手

具体通信过程：本体 UDP 在局域网内广播，Client 收到 UDP 广播后，调用 `RegisterContestant` 向本体注册，然后若 UDP 指定发送文件（区分搜索选手和收取选手文件两个功能。这里因为之前的注册过程已经获取到了所有 Client 的 IP，所以可以对点通信再发送收取文件的请求，需要再讨论一下，每个 Client 可以再成为一个 gRPC 的 Server，提供收取文件的接口），则遍历文件夹使用 `MakeDir` 和 `SendFile`。本体需要维护 IP 到 userName 的映射。

服务发现可以直接复用已有的公开技术栈，使用 mDNS+DNS-SD (Bonjour)，服务端注册 Bonjour 服务，客户端在局域网内查询服务。如果该校机房设置了计算机名，mDNS 也可以更简单地完成名称到 IP 的映射。

其他问题：关于端口的选择，需要确定两个端口，分别是 UDP 和 gRPC 的。

如果使用 Bonjour 则不需要提前约定 gRPC 端口， Bonjour 注册服务时可以现场填写，提供更大的灵活性；使用 Bonjour 的话则使用公开协议已有的接口，不需要自己定义一个单独的 UDP 广播接口，减少需要的防火墙调整。

上面其他问题主要是关于服务发现的。我提出用 UDP 广播的方式，主要原因是如果自己造轮子的话这样写最简单（

至于提到基于 mDNS 的方案，确实是符合标准的解决方式，但是至少我没搜到比较靠谱的跨系统通用的库（简单搜了一下），而且感觉小项目引入太多依赖也不太好。 以及这个方案如果把服务端定义为跑在选手机器上的，感觉会更 make sense。

防火墙确实是个问题，但不管怎样只要通过网络通信都绕不开这个问题。

Client 端 GUI 技术选择

考虑到 Client 端实现的功能较少，暂时有三个待选项

* Webview，用 Web 开发那一套理论，缺点是对老系统（比如 win7）的兼容性（不过好像本体已经放弃兼容了）

不好说，有可能会发生老师/学长用笔记本电脑在机房收取机房电脑上的代码的情况。但是个人觉得用 Webview 并不是很适合这个场景。

* Qt，接着用 C++

沿用本体技术栈可以降低用户的心智负担。

* Golang + Flutter，是否太重量级了

Flutter 中文和字体支持一直很烂。

那暂时就定下来继续使用 Qt 了（会增加开发者的心智负担）

---

总结一下

• 不使用 gRPC，使用 POST 或 GET 实现相关功能（RESTful API ?）。
• 服务发现还需要讨论：使用标准的零配置网络还是自己造轮子的 UDP 广播。
• 继续使用 Qt 开发。