Hi,
这是开源弹幕系统改进项目的第一次周报。
*项目规划 *
- 第一阶段项目研发
- 07/01 - 07/07 调研目前开源弹幕方案，研究 Comment9 和 danmaQ
，确定技术路线，兼顾性能，并设计弹幕服务端和弹幕客户端之间的通讯逻辑✅
- 07/08 - 07/15 重构弹幕绘制逻辑，使其同时兼容客户端和 Web
端，并能达到当前主流弹幕网站（Bilibili）的显示能力，并具有较高的拓展能力，基本实现弹显示功能，并完善设计文档✅
- 07/16 - 07/31
构建弹幕服务端和弹幕客户端之间的通讯逻辑，实现服务器推送弹幕的正确接受与绘制，增强弹幕客户端在不稳定网络下的故障恢复能力
- 08/01 - 08/15 在 Comment9
基础上升级弹幕服务端，完善各种功能并实现可拓展的弹幕接入（包括网页、微信、Telegram等），打通服务端与客户端，最终打包成docker实现一键化部署
- 第二阶段项目研发
- 08/16 - 09/30
基于第一阶段考核结果做相应改进，整理项目代码，实现语言国际化，完善相关文档，增强代码的易拓展性，实现版本的自动化打包发布，并提交软件包到
dockerhub 及 AUR 等仓库，进一步实现易用性。
*07/01 - 07/07*
- 尝试跑通 gdanmaku-server 失败，用 nginx 反代解决 demo ssl证书问题，尝试使用 danmaQ
- 修复了 danmaQ 部分显示、编译问题
- 基于需求和开源弹幕方案现状，保持当前的弹幕显示模式（滚动、顶部、底部，由于弹幕实体无法被完全穿透），增强颜色和字体大小等功能，下一阶段准备基于
CCL 协议设计实现，Web播放器基于 Danmaku.js 修改
<https://github.com/jabbany/CommentCoreLibrary>
*通讯逻辑*
- 播放器端预计有QT和web播放器、Web 弹幕墙（硬件弹幕机由于无法登陆 ssh 暂时放弃），*主动*
和服务端建立HTTP/WS连接，以WS为主，前期使用密码进行简单鉴权
- 服务器端采用Nodejs，触发式存储弹幕和建立连接，方便采用*Serveless形式*部署，使用web播放器实现在线预览和审核
- 弹幕发送器 前期 先支持网页（单用户）和WEB API（带管理员鉴权的多用户），后面通过 WEB API
接入微信、TG，外置探测程序接入Bilibili，接口保证拓展性
*核心逻辑*
弹幕发送器发送→（发送器/接收器生成uuid：基于ip或者管理员鉴权认定的用户唯一id）→服务器接收→人工审核→自定义二次处理函数（比如过滤黑名单、只输出同传字幕）→生成URL
HTTP+WS提供给播放器使用
直播结束后可以基于时轴生成备份文件。
*07/08 - 07/15*
*协议设计*
弹幕分为实时（直播）弹幕和回看弹幕，实时弹幕采用WS与HTTP混合，WS优先的协议设计；回看弹幕采用HTTP请求返回分页数据。
API 尽量保证与 Comment9 中原有设计相一致，HTTP部分使用 express，WS使用 Node.js 实现的 Socket.IO
<http://socket.io/> v4，同时保证其在QT中的兼容性。
*弹幕设计*
基于 CommentCoreLibrary 以及现状做的弹幕结构设计，前期保留拓展项目接口。
HTML5播放器已经有了基本可用的实现
<https://github.com/jabbany/CommentCoreLibrary>
*API 设计*
管理相关API 需要 session
鉴权，使用HTTP接口；活动作为弹幕盒载体，使用HTTP接口；审核接口考虑效率使用Blacklist（效率不高）+
自定义函数，考虑安全性的话可以让用户提供外置API接口。
*弹幕接口 - WS/HTTP*
按照核心逻辑设计 API
弹幕发送器发送→（发送器/接收器生成uuid：基于ip或者管理员鉴权认定的用户唯一id）→服务器接收→人工审核→自定义二次处理函数（比如过滤黑名单、只输出同传字幕）→生成URL
HTTP+WS提供给播放器使用
WS （SOCKET.IO）
使用 token 鉴权
*/comment/:token/?param (param用于过滤mode)*
Client: push JSON
发送封装好的弹幕
Client: pull
获得最近 5s 的弹幕
Client: pull JSON
获得自定义时段的弹幕
Server: JSON
自动发送最新的弹幕
HTTP
ALL /comment/wechat/:token
GET /comment/player/:token/pull?param
POST /comment/player/:token/push
*关于 Token 安全性*
当前的设计是不同权限给不同 Token ，还算合理。
*弹幕审核*
初步设计每个活动归一个用户所有，这个用户拥有审核的权限，并且可以生成审核专用token。
*下一阶段：*
- 整合 Socket.io <http://socket.io> 和 QT5，基本就合并CMAKE，能跑通 Node.js 和 QT
间通讯就行，这样基本保证稳定连接。
- 实现MangoDB下的各API功能，再简单接入QT5和HTML5播放器。
- WSS/TLS 应该可以直接反代套在最外层，先不考虑。
*下下阶段：*
- 接入 Wechat & Telegram，用户 Token 管理（考虑 Wechat 接口解耦合）
- 设计简单用户管理&前端页面
*Papersnake*
--
您收到此邮件是因为您订阅了 Google 网上论坛的“TUNA 主邮件列表”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到tuna-general+unsubscr...@googlegroups.com。
要在网络上查看此讨论，请访问
https://groups.google.com/d/msgid/tuna-general/1f12dd8a-8970-4aad-bdb4-1b31b2d47d5bn%40googlegroups.com。
