每五秒执行一次_纪念一次离谱的Coursework

大家晚上好！！！又是好久没更新了~

【前言】

在开学前本以为大三的生活依然是风花雪月，我的生活状态依旧是潇洒如鹰，虽然知道这一年学习肯定是要更忙一点，但总认为仍然有足够的时间去给我享受眼前生活。但大半个学期过去了才发觉，整个人每天都在被各种情绪牵扯，因为我今年明显感觉到无法把学习和生活平衡得那么好，虽说得失有数，但为了更高的目标放弃一些东西也的确很难受吧。别的感受也不想多言，我现在只想把它们封存起来，等一年之后再回溯这些宝贵的记忆点，我希望所换来不是刻舟求剑的无奈，而是一种油然而生的想法：这些宝贵的时间碎片是我今年最大的奖。

好久没写过学术类的推文了，今天这期想分享一下自己这周来对一个极其离谱的coursework的想法(但这仍然是一个很私人的记录自己心路的公众号！！)

【吐槽】

没错，我想写的就是CAN 201的CW1。别的先不说，拿到这个cw的task sheet时我整个人就直接懵了(见下图)。整整六页描述要求和评分规则，入门CS到目前为止我还真没见过要求那么多的cw，而且这个cw不是一般的难。

为什么难？第一，虽然都嘲讽ICS是自学专业，这点我一直否认，但这次无话可说，实现这个需求所用到的技术和操作老师课上几乎没教，所给的sample code相对来说也只是一种敷衍(就比如讲到Socket编程时连最基本的recv函数的用法都不说)。第二， 要求太多，读完这个要求就能感觉到这差不多要求我们做一个工业级的应用，而且还是大三学生在有限的几周时间内单人开发(而且这个cw直接占比55%啊)...... 第三就是这个cw技术性太高而且对大家不公平。多线程多进程并发加锁，提高效率甚至考虑一下数据结构的选择和算法使用，在linux虚拟机内测试...... ICS专业的学生还好，至少在大二这一年学过相关课程，但这次还有很多其他专业的学生做这个cw，公平吗？之前也做过一些比较难的coursework，比如大二上学期GUI实现窗口的缩放是一个难点，大二下学期TSP问题怎样选择合适的数据结构和算法来优化路径也不简单，但它们都只是难在一个点上，至少还是在可控的范围内，而这次几乎每一个模块里面都有难点(怎样检测文件的存在，怎样检测对方在线，断点怎样恢复，怎样发送文件夹......)再说一下我的背景，专业前十，做过一些开发项目拿过一些比赛奖项，虽然说算不上很强，但作业出的让这种能力的学生都觉得无法下手，只能说着实失败。做了大概有10天了，当然每个人都有自己的思路，设计出来的应用也肯定不一样，下面主要说一下我目前的想法。(只是思路，不涉及代码层面)

【思路】

很多人只是以为本次cw的重点在文件传输，当然没什么问题，但我在实现过程中发现更重要的是protocol的设计和如何把所有要求都实现而且不能有冲突(Ethan目前还剩下断点续传和部分修改两块没有做)。为了能给自己一个清晰地设计思路，我主要从detection，file transfer，protocol design， other details四个方面考虑，最后在实现的时候不断修改调整并把它们汇总起来(老敏捷开发了)。

Detection

首先一点要明确的是，我设计的是一种主动模式，就是检测到文件出现直接发送，而不是等着对方来跟你要，那么这个cw与其说是file sharing倒不如说是file synchronization。根据sheet的描述我们可以知道，现在有三台机器都跑着同一个程序(也可能还没启动)，在其中一台机器的share文件夹下放进一个文件，另外两台机器需要自动同步。底层先不说，这里就已经涉及到两个很重要的问题：1. 怎样检测到有新的文件加进来了？2. 怎样检测另外的机器online？说一下我的解决方法。我们可以开一个线程持续监测share下是否有文件加入，也就是while里面用os.listdir返回一个文件数组，记下这个数组的长度，当数组长度发生变化时就说明有新的文件加入，那就要找到这个新加的文件是什么(这里在代码层面还是有一点东西的)。因为sheet的描述里没有删除文件的操作，所以在这里我们不考虑数组长度的减少。还有一点需要注意的是怎样判断加进来的是一个文件夹？注意到普通的文件结尾都有扩展名，这就很好办了，此处不详细说明。第二点就是如何检测对方在线，我的方法是持续广播。首先我们肯定知道对方的ip地址和相应的端口号，那就比如每隔五秒我就用udp的socket给对方发送一个封包。如果对方不在线我们这边就收不到回复，一旦对方上线收到我们的封包，我们可以让他回复一个东西(一个bit就好)，当我们这边收到这个bit时就表明，对方上线了，我可以和他通信了(这里的code也很有技巧)。

Protocol Desgin

当以上两部做完后就要把检测到的文件发送给对方了，这就不免涉及到了最关键的一部分：protocol header的设计。protocol就是程序的一问一答，根据相应的问题作出相应的动作。为什么要protocol？比如在单一的设计模式下，所有收到的文件都做相同的处理，可我要发送的是一个文件夹呢？你还只是读取文件然后写入？这就毁了。还有我收到你发来的东西我怎么知道是要做文件写入还是回复你代表我在线呢？所以说我们每次发送信息前需要加一些额外的信息在开头来告诉对方(我喜欢用一个bit来表示)我发的这条信息是想干嘛的，对方看到后才会明白你的意思，执行相应的操作，这就是所谓的protocol。所以在我的设计模式里，我会写检测对方是否在线、询问对方是否有这个文件、发送具体文件、对文件夹操作这些protocol，并把它们都统一起来。当把protocol设计出来后这个cw的代码部分已经算完成70%了，当然说起来简单，但protocol设计的下面有很多细节需要注意，有一点没考虑到很有可能全盘崩溃。这也是我认为最难的部分。

File Transfer

这是最令我难受的一个模块，因为我花了前五天甚至第一周都在研究怎样能使文件传输更快而且不丢包不错误，但最后没有任何收获(可能是因为我能力不够)只能按部就班。先说一下多线程的问题，老师在课上说用多线程分别负责程序的一些block的传输可能会使传输时间缩短。在理论上这当然是没有问题的，而且对于TCP而言，在一定频宽的网络下，建立的TCP连接数越多，那么抢到的频宽就越大，传输的速度也会更快。但是经过我的测试和大佬们的讨论，在一周后我才发现，python里面的多线程是假多线程！！！也就是虽说是多线程，但每一个线程并没有被映射到计算机内的每一个内核上，他还是一个核跑那么多线程(欲哭无泪、身心俱疲、生无可恋)...... 但是在python里面多进程可以被映射到每一个内核上面，但是每启动一个进程是非常浪费时间的，可能人家单线程传10M的文件瞬间就过去了，你还得一个个线程启动再发送，不知道慢成什么样。更重要的是多线程还得考虑race condition和先后顺序等一些问题，可能你写入文件内容的顺序是乱掉的，这还得考虑用数组下标来表示block啥的，特别烦，线程开多了程序甚至也可能崩掉。所以我就不浪了，直接一条线程把文件分block慢慢传吧，最多再判断一下文件大小加个压缩什么的。如果说功利的话最多也就丢个三四分吧，能把多线程跑顺的大佬也应该是少数。

Other Details

剩下的是一些advanced要求(断点续传，部分修改)和一些细节(如何处理文件夹，如何压缩)，因为我还没有完全做完，虽然有想法，但还不知道能否实现，在这里就不说了。有想法的朋友们有时间时可以一起讨论~

【尾声】

emmm这次就写这么多吧，主要是想记录一下自己做这个cw时的心境和分享一些想法，希望能帮助到有需要的朋友们，也许过了几个月自己看也会觉得当时自己好热忱啊hhhhh。最后在这个十分离谱的cw前，希望大家都能互相帮助，一起度过难走的一关。