Thunder_Class
Thunder_Class copied to clipboard
profthecopyright
关于设计思路的若干问题
- 根据老师在4.21晚习题课的讲解，这里面的传输C/S模式应该是老师（主持会议方）为服务端，建好之后IP告诉同学让同学（与会者）用客户端加入，数据库也是老师保存在本地，共享屏幕仅教师端可以使用，双方是不平等的关系。当然答辩的时候展示同学作为假想的“老师”。你的设计思路中单独一个服务端的想法不符合需求。
- 使用纯UDP传输与多处需求相悖，相比传输速率，大作业里稳定性显然更重要。
- 共享屏幕不要求实时，一秒钟一帧十秒钟一帧都是可以的，如果你要是用 ffmpeg 的话记得把 ffmpeg 加入你的项目里作为代码一部分，然后和你原本的代码一起编译得到同一个exe，不得使用dll等。
- Qt早就成了自动化小学期的Baseline，这都2020年竟然要用MFC吗？
- 想蹭热度无可厚非，但是搞一堆不符合需求的东西，要是真让需要完成作业的同学看见，走偏了方向，最后辛苦爆肝几星期拿个及格分，你作何感受？
感谢指出。关于这个项目的目的已经在《废话说在前面》写得很清楚了，无意让任何人直接抄作业，也不对此项目的结果负责（参见GNU License）。任何人认为有不合适的地方可以修改、贡献、参与、讨论，这也就是为什么这个项目摆在github上的原因。接受建设性批评和修改，但如果只是纯引战请绕道。
- 欢迎提供要求细则的资源。我目前并没有更多的资源，只能从已公布的文档字面上理解Admin管理员和教师端是两个不同的权限设定。如果教师可以兼具Admin功能那么流程会大大简化。
- 第一次迭代仍然计划仅使用UDP，先做出一个可以用的模型，之后关于不同类型消息传输的优化问题可以在社区讨论基础上更新。
- ffmpeg的官网上有源码。我会注意此要求。个人理解如果是教学用软件，尤其是要配合屏幕操作演示的话，帧率是要达到一定要求的，同时要进行音画同步（仅演示ppt可以要求相对低一些）。但如果老师要求提出了帧率限制/不作限制，则会作出相应考虑。
- 我并不了解自动化小学期要求什么不要求什么（顺便提一句，自动化系目前大一的学生可能还没有经历过小学期吧，是否人人都会用Qt求进一步验证），只是暂时不想引入过多非必要的第三方库。毕竟开源社区如果每个参与者都要求配置很多第三方新的依赖项会很麻烦。Qt可以MFC可以UWP也可以，初步选择MFC只是因为个人认为相对比较简便，但不排除之后的版本中变换实现方式。
- 参见上一条。
有更详细的细节说明当然欢迎啦。毕竟除了上课的同学，其他人不会每节课都参加。只看文档理解都会有偏差的。所以估计写着写着就变成自己的理解了，最后去追求一些奇怪的点我觉得都正常（例如：搞一下实时）。
我看这个 repo 就是个人自己写着玩啦。不用期望太高。
我OCR的时候浏览过一遍编码规范，要求比较多。所以我认为有必要自动化，这种对真正上课的同学们也有益，如果能整出个自动化的cheker说不定还能给助教用😀。 同时其他人写就没有必要遵守这个。(-20% 警告⚠
第三方库的源码编译要求我都觉得可以先放放，等你确定这个好用再去折腾源码编译。 给大家踩踩坑，看那些 API 好使比直接参考他人的代码强。 毕竟读别人的代码是一件乐趣无穷的事情。
（看来废话得放几句到 Readme 里。
有更详细的细节说明当然欢迎啦。毕竟除了上课的同学，其他人不会每节课都参加。只看文档理解都会有偏差的。所以估计写着写着就变成自己的理解了，最后去追求一些奇怪的点我觉得都正常（例如：搞一下实时）。
我看这个 repo 就是个人自己写着玩啦。不用期望太高。
我OCR的时候浏览过一遍编码规范，要求比较多。所以我认为有必要自动化，这种对真正上课的同学们也有益，如果能整出个自动化的cheker说不定还能给助教用😀。 同时其他人写就没有必要遵守这个。(-20% 警告⚠
第三方库的源码编译要求我都觉得可以先放放，等你确定这个好用再去折腾源码编译。 给大家踩踩坑，看那些 API 好使比直接参考他人的代码强。 毕竟读别人的代码是一件乐趣无穷的事情。
（看来废话得放几句到 Readme 里。
你愿意负责自动化代码checker吗
别的我都不说了。不要用UDP（除非你有现成的东西），坑多得很，光解决UDP的问题就够你做2年了。 用TCP在良好的网络下的效果和UDP相当，在网络环境不好的情况下，UDP确实可以做的比TCP好，但是很难。
QoS回传，拥塞控制，报文重排，重传（虽然音视频流有些数据丢了无所谓，但是有些却是不能丢的，或者丢了对效果影响非常大）等等……每个一都是难题
别的我都不说了。不要用UDP（除非你有现成的东西），坑多得很，光解决UDP的问题就够你做2年了。 用TCP在良好的网络下的效果和UDP相当，在网络环境不好的情况下，UDP确实可以做的比TCP好，但是很难。
QoS回传，拥塞控制，报文重排，重传（虽然音视频流有些数据丢了无所谓，但是有些却是不能丢的，或者丢了对效果影响非常大）等等……每个一都是难题
其实我不确定到时候的测试环境是什么样的 如果是一个学生在家里演示 然后几十个人围观的话 怕TCP会炸 初步考虑UDP其实主要是出于这个至少能用的考虑 我倾向于把控制指令过渡到用TCP 音视频暂时随缘了 毕竟做完第一个版本以后我就打算放手了 如果这个repo真能活两年/有人可以贡献现成的/改协议的话 那喜大普奔
不过要是像上面说的对帧率没要求的话 可能我会倾向TCP了 毕竟分享ppt画质不用多少带宽（狗头
别的我都不说了。不要用UDP（除非你有现成的东西），坑多得很，光解决UDP的问题就够你做2年了。 用TCP在良好的网络下的效果和UDP相当，在网络环境不好的情况下，UDP确实可以做的比TCP好，但是很难。 QoS回传，拥塞控制，报文重排，重传（虽然音视频流有些数据丢了无所谓，但是有些却是不能丢的，或者丢了对效果影响非常大）等等……每个一都是难题
其实我不确定到时候的测试环境是什么样的 如果是一个学生在家里演示 然后几十个人围观的话 怕TCP会炸 初步考虑UDP其实主要是出于这个至少能用的考虑 我倾向于把控制指令过渡到用TCP 音视频暂时随缘了 毕竟做完第一个版本以后我就打算放手了 如果这个repo真能活两年/有人可以贡献现成的/改协议的话 那喜大普奔
不过要是像上面说的对帧率没要求的话 可能我会倾向TCP了 毕竟分享ppt画质不用多少带宽（狗头
同学别担心，虽然是应用层做广播，但是其实不怎么吃CPU的（吃CPU说明你程序没写好），主要还是吃带宽。另外路由器也不会转发广播数据包，IP层广播只能在一个小局域网内工作。
话说我学生时代也有类似的困惑……后来发现其实大家都是应用层广播，手动狗头
别的我都不说了。不要用UDP（除非你有现成的东西），坑多得很，光解决UDP的问题就够你做2年了。 用TCP在良好的网络下的效果和UDP相当，在网络环境不好的情况下，UDP确实可以做的比TCP好，但是很难。 QoS回传，拥塞控制，报文重排，重传（虽然音视频流有些数据丢了无所谓，但是有些却是不能丢的，或者丢了对效果影响非常大）等等……每个一都是难题
其实我不确定到时候的测试环境是什么样的 如果是一个学生在家里演示 然后几十个人围观的话 怕TCP会炸 初步考虑UDP其实主要是出于这个至少能用的考虑 我倾向于把控制指令过渡到用TCP 音视频暂时随缘了 毕竟做完第一个版本以后我就打算放手了 如果这个repo真能活两年/有人可以贡献现成的/改协议的话 那喜大普奔 不过要是像上面说的对帧率没要求的话 可能我会倾向TCP了 毕竟分享ppt画质不用多少带宽（狗头
同学别担心，虽然是应用层做广播，但是其实不怎么吃CPU的（吃CPU说明你程序没写好），主要还是吃带宽。另外路由器也不会转发广播数据包，IP层广播只能在一个小局域网内工作。
话说我学生时代也有类似的困惑……后来发现其实大家都是应用层广播，手动狗头
我就是担心带宽= =总感觉同学家里的网会不好（
网络不好（在你把UDP的一系列可靠性问题解决之前）就更不能用UDP了，原因刚才说过。
另外整个演示不可能都在同学家吧，否则UDP广播就没法用，路由器不转发广播包（刚才说过），于是用UDP还得应用层端对端转发……于是该有的流量还得有。
网络不好（在你把UDP的一系列可靠性问题解决之前）就更不能用UDP了，原因刚才说过。
另外整个演示不可能都在同学家吧，否则UDP广播就没法用，路由器不转发广播包（刚才说过），于是用UDP还得应用层端对端转发……于是该有的流量还得有。
谢谢指点！