2020 年 4 月 2 日更新，接到新网银行电话，要求移除 github 上相关代码，我们已经把我们发布的代码设为私有。
大概 10 月中旬看到了一封 SegmentFault 的邮件，提到这个比赛，发现分布式赛道的题目很有意思。
比赛是 9 月 18 日开始 11 月 15 日结束，但是由于比较忙，直到 10 月底我才第一提交代码，11 月初我们正式组队 (已失效) 开始参加初赛，我们几乎都是使用业余时间完成初赛代码 (已失效)。后来有幸进入决赛，在成都参加了线下马拉松，决赛我们有不少失误，虽然成绩远没有预期的理想，但是我们收获很多。
初赛
我们获得了 1124.82 的最总成绩。（满分 1200）
我们的特色主要是可视化和辅助工具。我们队的时间非常紧张，因为参赛太晚，而且工作日学校还有很多事情。准确评估解决方案的效果和缺陷，快速迭代，是我们初赛取得好成绩的关键。
自主实现的判题机代码
我们实现的初赛判题机代码仓库 (已失效)
虽然时间很紧张，但是我们还是仔细阅读了判题机的所有代码。（比赛期间是提供了判题机代码的，现在似乎没有了）还写了一个代码阅读笔记，虽然耗时，但是值得。
为了更高效的实现自动化结果评估和拓扑、路由可视化，我们自己动手写了一个判题机。主要的理由是：
- 我对 c++ 不够熟悉
- 我希望使用 阻塞套接字
- 输出结构化日志
- 判题机自动启动、停止客户端进程
- 使用消息驱动（异步）
- 跨平台
上述目标基本实现了。
windows 10 本地测试 950 节点的资源占用：
图截的不好，这里主要看内存，CPU 占用高是因为这是启动过程中大量创建进程。实际运行过程用 CPU 负载不高。主要是内存占用高。
结果评估（自动输出）：
最坏情况路由分析（手动的）：
消息哈希：4658B1314C
源点：943 (主根 897)
目标：401 （主根 385）
时延：2.21
转发跳数：19
路由：
[943, 0.6682496070861816]
[920, 1.824514627456665]
[908, 2.1567699909210205]
[902, 2.199902057647705]
[899, 2.242053747177124]
[898, 2.2840933799743652]
[897, 2.326270580291748] (到达本树主根)
[1, 2.3676204681396484]
[65, 2.409736394882202]
[129, 2.451462745666504]
[193, 2.493069887161255]
[257, 2.5348517894744873]
[321, 2.576202630996704]
[385, 2.617375612258911] （到达目标主根）
[386, 2.6591007709503174]
[387, 2.70068359375]
[389, 2.741595983505249]
[393, 2.7833566665649414]
[401, 2.8250982761383057]]
可视化程序
环形拓扑，使用了 svg 和原生 javascript。
树环拓扑，使用 echarts 的力导向图。
基本思路
实现静态路由作为网络的主干，两个优化分支：
- 通过局部的动态路由算法。
整体的拓扑调整，不断向最有拓扑演进（此策略我们做的效果不好）
环形拓扑
树环拓扑
示意图：
可视化图：
- 临时链路优化
对于路由条数超过阈值的消息，在按照路由转发的同时，尝试建立一条直通链路（有可能失败），直接发送。
决赛
决赛的场景有了较大的改变。相比之下，拓扑不再那么重要，而路由算法更能影响分数。
两种思路：
- 由于节点改变服务类型的时延极高，因此我们在节点处理当前数据包，预先将下一跳节点的服务类型切换为数据包下一个服务类型，边移动边处理
固定角色，两套路由：一套是路由到指定服务，一套到指定节点。
我们获取了初始的服务状态，发现分布比较均匀，且各类型服务都有：
服务分布：
服务类型比例：
决赛的问题
我们两种思路都没能做的完善，虽然我们几乎没怎么休息。决赛里我们确实失去了初赛时候的很多优势。没有充足的时间调试。初赛我们的 python 方案完全抛弃了官方的示例程序。而是自己实现的，但是决赛里我们没有这么做，主要是考虑时间问题。而决赛的 c++ 示例程序中潜藏的问题非常的多，让我们应接不暇，最终我们只好彻底放弃了 c++ 方案的开发而集中力量开发 python 方案。非常遗憾的是我们的两种思路都没能做好。
相关链接
比赛官网
DC竞赛-分布式路由赛道初赛初赛代码仓库 (已失效)判题机代码仓库 (已失效)