计网lab摆烂记
下面为博客摘要，详细内容请看http://keke046.github.io/2021/12/01/mofish/compute-network/
其实通过一些统计学原理，从哪儿收到广播包，就把其它包给它发回去，就已经可以路由了。**本文和文中图片纯属虚构，纯属调侃，大家笑得开心就行了，不要当真**!-- more --lab要实现路由算法，于是设计了一个GRP，"The Grand Protocol"，把IP，MAC，相邻节点，还有一些metadata全部塞一个Grand Packet包里。就干脆把return给define掉：```c++#define return cond_var。乱搞真香。jpg 600 %}!-- img src="compute-network/complex-10-node。好像IP包最大只能65535，不管了，直接忽略IP头。要多线程，麻烦。png" style="zoom:50%;" / --unitest写几个，gcov跑一跑，然后瞎搞搞，真是完美的协议栈。png" style="zoom:50%;" / --打开lab提供的perf程序，试了一下，接收方缓冲1G，发送方一个包65k，最后网速3k/s。发送端发送窗口也没有限制，直接无穷大，全部给我发，收不到就重传，慢慢重传。弄一个大一点的网络，两两发包。大不了就拥塞嘛，没有问题，只要我不停传，总会有传到的那一天。jpg" style="zoom:50%;" / --根据实验，就算每一对IP发1byte数据似乎也不能全部完成，太烦了，干脆时间到了就全部给我强行停止。。。。。所有尝试简化TCP让它变得条理清晰，或者用C++的特殊语法来优化代码的尝试都失败了。闪亮~。{% asset_img complex-10-node。然后这个包在L2和L3疯狂广播，到处发。但是一个新节点加入之后，它要等一会才能收到其它节点的广播。然后sender没有考虑优先级，ACK太多，收ACK把线程占满没法发包了，于是把RTT开得更小，加快重传的频率，让sender重传的速度打赢receiver发ACK的速度，避免饥饿。不管了，每次调用read就给回一个ACK。。{% asset_img 2021-11-28-15-37-58。perf好像要测10次，每次发1M流量，居然要跑10分钟，正好去买个奶茶。直接整个程序一个锁，一个条件变量。打出log来看，sender和receiver交替进行大量重传，完美地工作着。。设计了一个特殊frame，收到这个frame的人会广播自己Grand Packet。感觉TCP就像克苏鲁一样。嗯，真是一大创举。{% asset_img image-20211201215831564。接受端缓冲区大小好像没有限制，那就直接开1个G。测了一下，很好，和设计的一样，重传率接近100%，重传流量占总流量的80%。还要写一个benchmark来测试网络的性能，那就测一些发出了byte数和重传的byte数的比例吧。。png 600 %}!-- img src="compute-network/image-20211201215831564。但还是写了一个dijkstra来求最短路，感觉做了很多无聊的事情。刷的一下就起来了（大雾然后要写TCP，好像虚拟网卡包的大小是可以随便改的，OK，直接一个包1M。!-- indicate-the-source --计算机网络lab，手写链路IP和TCP，重写了至少3遍TCP之后，废弃了约1500行代码后，成功躺平，开始乱搞。测的时候，还发现了一些奇特现象，比如socket没有建立连接就收到了包（因果律打击），包发到一半就消失了，线程没有调用join就显示被join过了……没有任何问题，一个`close`，线程全杀死，问题全消失。新加入的节点只要广播这个特殊frame，就能让网络里所有节点同时广播自己的数据。notify_all(); return```接受窗口空了zero window，本来应该用计时器，来防止sender和receiver死锁。后来测试程序调用的是getline，getline是一次一次read(1)，于是一个包有多长，就会发回去多少个ACK。png 600 %}!-- img src="compute-network/2021-11-28-15-37-58。所有线程都去给我锁，每个函数return之前都去notify那个条件变量
计算机网络lab，手写链路IP和TCP，重写了至少3遍TCP之后，废弃了约1500行代码后，成功躺平，开始乱搞。
感觉TCP就像克苏鲁一样。所有尝试简化TCP让它变得条理清晰，或者用C++的特殊语法来优化代码的尝试都失败了。
乱搞真香。
本文和文中图片纯属虚构，纯属调侃，大家笑得开心就行了，不要当真
其实通过一些统计学原理，从哪儿收到广播包，就把其它包给它发回去，就已经可以路由了。**本文和文中图片纯属虚构，纯属调侃，大家笑得开心就行了，不要当真**!-- more --lab要实现路由算法，于是设计了一个GRP，"The Grand Protocol"，把IP，MAC，相邻节点，还有一些metadata全部塞一个Grand Packet包里。就干脆把return给define掉：```c++#define return cond_var。乱搞真香。jpg 600 %}!-- img src="compute-network/complex-10-node。好像IP包最大只能65535，不管了，直接忽略IP头。要多线程，麻烦。png" style="zoom:50%;" / --unitest写几个，gcov跑一跑，然后瞎搞搞，真是完美的协议栈。png" style="zoom:50%;" / --打开lab提供的perf程序，试了一下，接收方缓冲1G，发送方一个包65k，最后网速3k/s。发送端发送窗口也没有限制，直接无穷大，全部给我发，收不到就重传，慢慢重传。弄一个大一点的网络，两两发包。大不了就拥塞嘛，没有问题，只要我不停传，总会有传到的那一天。jpg" style="zoom:50%;" / --根据实验，就算每一对IP发1byte数据似乎也不能全部完成，太烦了，干脆时间到了就全部给我强行停止。。。。。所有尝试简化TCP让它变得条理清晰，或者用C++的特殊语法来优化代码的尝试都失败了。闪亮~。{% asset_img complex-10-node。然后这个包在L2和L3疯狂广播，到处发。但是一个新节点加入之后，它要等一会才能收到其它节点的广播。然后sender没有考虑优先级，ACK太多，收ACK把线程占满没法发包了，于是把RTT开得更小，加快重传的频率，让sender重传的速度打赢receiver发ACK的速度，避免饥饿。不管了，每次调用read就给回一个ACK。。{% asset_img 2021-11-28-15-37-58。perf好像要测10次，每次发1M流量，居然要跑10分钟，正好去买个奶茶。直接整个程序一个锁，一个条件变量。打出log来看，sender和receiver交替进行大量重传，完美地工作着。。设计了一个特殊frame，收到这个frame的人会广播自己Grand Packet。感觉TCP就像克苏鲁一样。嗯，真是一大创举。{% asset_img image-20211201215831564。接受端缓冲区大小好像没有限制，那就直接开1个G。测了一下，很好，和设计的一样，重传率接近100%，重传流量占总流量的80%。还要写一个benchmark来测试网络的性能，那就测一些发出了byte数和重传的byte数的比例吧。。png 600 %}!-- img src="compute-network/image-20211201215831564。但还是写了一个dijkstra来求最短路，感觉做了很多无聊的事情。刷的一下就起来了（大雾然后要写TCP，好像虚拟网卡包的大小是可以随便改的，OK，直接一个包1M。!-- indicate-the-source --计算机网络lab，手写链路IP和TCP，重写了至少3遍TCP之后，废弃了约1500行代码后，成功躺平，开始乱搞。测的时候，还发现了一些奇特现象，比如socket没有建立连接就收到了包（因果律打击），包发到一半就消失了，线程没有调用join就显示被join过了……没有任何问题，一个`close`，线程全杀死，问题全消失。新加入的节点只要广播这个特殊frame，就能让网络里所有节点同时广播自己的数据。notify_all(); return```接受窗口空了zero window，本来应该用计时器，来防止sender和receiver死锁。后来测试程序调用的是getline，getline是一次一次read(1)，于是一个包有多长，就会发回去多少个ACK。png 600 %}!-- img src="compute-network/2021-11-28-15-37-58。所有线程都去给我锁，每个函数return之前都去notify那个条件变量