转眼到了8月初。
今天，陆怀民准备做一次完整的闭环链路测试。
陆怀民只做了两个委派：
CN区交给8号机，DE区交给9号机。
CN区就是属于中国的顶级域，DE区是属于联邦德国的顶级域。
8号机和9号机分别是这两个区的权威服务器，区文件里各自存了几条主机记录，其中一条记录挂在mail.cn名下，这个地址是测试数据的域名。
10号机和11号机就是两个区的客户端。
搭建做完后，陆怀民开始今天的调试。
10号机客户端先做出了“query sent”的提示，报文发往了根服务器，也就是7号机。
随后7号机提示收到查询，但并没有直接回答，而是回了一条委派：
关于CN区查询访问，去8号机（也就是CN区的权威服务器上）查询。
陆怀民又去8号机。
8号机上先是提示收到查询，再是一行查找区文件的记录，最后一行应答从那里出去：
ANSWER：mail.cn，A，10.9.0.20，TTL 86400。
（DNS服务器返回答案：域名mail.cn的 A记录，IPv4地址是10.9.0.20；这条解析结果允许 DNS缓存 24小时。）
这条应答也代表着整个查询链路第一次完成了闭环！
而在这套新系统中，第一个被完整解析出来的域名就是mail.cn。
陆怀民脸上露出一丝振奋之色。
他连忙又测试了De区的查询链路。
和cn区的过程类似，不过这一次是11号机提问，随后转到根服务器委派9号机回答。
最终9号机返回了类似的结果。
第二次查询链路测试成功！
陆怀民连忙写观测日志：
“一九八二年八月三日，6:33。第一次完整闭环链路测试成功。”
紧接着，他把整条链路上每一份报文的来路和去向，都记录得清清楚楚。
这都是第一手的实验资料，需要写到论文里的。
当然，闭环跑通虽然是一时的大胜利，但一套分布式命名系统，单次链路走通还是远远不够的。
他要在接下来一段时间，把整套架构从根服务器、权威服务器到解析客户端，逐个地验证一遍。
这套在做实验中有一套专门叫法。叫“全矩阵验证”。
接下来的几周，陆怀民就要完成他这个项目的全矩阵验证。
后面几天，陆怀民完成了跨区查询。
接着就是验证缓存，然后就是否定缓存。
8月16日，陆怀民完成了区域传输的验证。
8月17日是最后一项故障演练。
陆怀民在实验过程中，将一台计算机强制关机，以模拟故障发生时的情况，看看解析器如何反应。
计算机关机的一瞬间，十号机在屏幕上做出回应：服务器暂时无法应答。
不过解析器没有崩溃，而是给出了一条明确的错误提示，最后安静地等待。
一分钟后，八号机重新开机，区文件重新加载，权威服务恢复。
十号机再查，一切照常。
至此，整个全矩阵验证也基本完成。
第二天上机，陆怀民最后过了一遍整个流程，完成了最后一次实验。
随后，他把这一个多月以来的抓包记录、观测日志、代码清单全部归拢起来。
好在陆怀民买的那台IBM PC配了一台爱普生点阵打印机，正好可以用那台打印机把这些所有资料都打印成册。
论文陆怀民这段时间也基本写完了，加上这段时间断断续续在实验过程中增加的附录。
最终是241页的论文加97页的附录。
足足300多页，可见这个项目并不是那么简单。
论文写完之后，陆怀民第一时间给施耐德教授的办公室打个电话。
接电话的是施耐德教授的学生，他说教授不在办公室，让陆怀民留了个名字，说下午3点以后来找。于是陆怀民便约了三点半。
下午三点半，陆怀民来到办公室找施耐德教授。
教授的办公室的大门敞开着，不过他正在埋头看着文献，于是陆怀民敲了敲门板，吸引他的注意力。
施耐德教授闻声抬起头，看见是陆怀民，他微微点了点头:
“Herr Lu，来了？坐。”
“施耐德教授，下午好。”陆怀民在办公室对面的椅子上坐了下来，开门见山地说道：
“我今天来，主要是想向您道谢。”
“道谢？”施耐德教授摇了摇头：
“没什么可道谢的。实验室资源本来就应该拿来做实验用的。只是我想问，你的实验做得怎么样了？特别是，有没有做出一些有价值的成果？要不然这段时间可就是虚度光阴、浪费实验资源了。”
陆怀民点了点头，说：
“教授，我今天正想说这件事：我的实验已经做完了，我的上机时间可以分配出去了。”
“做完了？”施耐德教授明显有些意外。
“对，做完了，我的论文也写完了。今天来也是想告诉您一声，我准备正式投稿了。”
施耐德教授闻言更加意外了。
在他的印象当中，他当初根本不看好陆怀民做的这个项目，不认为他有什么发表的价值。
他只是冲着陆怀民项目设计做的十分用心的份上，每天给了他一个机会，让他试试。
而且陆怀民的上机时间也仅仅只有40多天，每天1小时，也就40多小时，能做出什么名堂？
“我能看看你的论文吗？”施耐德教授不由得提起了些兴趣，好奇地问道。
“当然可以。”陆怀民说着，将准备好的论文递给了施耐德教授。
施耐德教授乍一看，更是大吃一惊，因为这本论文足足有300多页，看起来十分厚。
这更出乎了施耐德教授的意外，他下意识地脱口而出：
“这么厚？”
陆怀民笑了笑，解释道：
“正文241页，附录97页，一共338页，您看看。”
施耐德伸手将论文接了过去，实实在在地掂了掂。300多页的稿子，确实就像一本大厚书一样。
不过他心里也转了个念头：
论文写得厚也未必代表内容丰富。
他带研究生快20年，见惯了用厚度掩盖空虚的稿子。
300页的毕业论文，他每年都能审好几本。
水分挤一挤，能剩50页干货就算不错了。
不过，那些都是博士生的毕业论文。
平时做的项目能写成几百页的论文，他确实也是第一次见。
“你准备投哪家期刊？”教授随口问道。
“不投期刊，”陆怀民说，“我打算投给 RFC编辑委员会。”
“RFC？”施耐德教授闻言大吃一惊，“你确定？那是 ARPANET标准文档体系，不是学术期刊。”
陆怀民点点头：
“我知道，所以这篇论文是按 RFC备忘录格式写的。”
施耐德教授不由得坐直了身子，重新打量眼下的年轻人。
RFC，全称是Request for Comments，名字译作“征求意见稿”。
看这名字听起来没什么，但实际上却是整个互联网圈子很有分量的一个东西。
互联网圈子内，包括网络协议、传输规则、命名约定、路由规范，凡是网络运行的底层规则，全部以编号的RFC形式发布。
一篇文档一旦被赋予编号，全世界的所有联网的主机，所有写程序的工程师都要照着它制定的标准运行。
换句话说，RFC虽然不是论文，但确实可以说是未来网络的规则草案。
当然，RFC也有分级。
首先是标准类 RFC，它是互联网强制遵循的协议规范，属于互联网底层基石文档。
其次是实验性 RFC，它描述一种原型系统或新构想，不一定马上部署，但很多后来伟大的协议最早都起源于实验性 RFC。
换句话说，实验性 RFC如果足够出色，能被全球的网络研究者认可，后面也可能进化为标准类 RFC，成为互联网的底层文档。
当然，就算实验性 RFC没有进化成标准 RFC，那在互联网行业内，含金量依旧相当的高。
因为它代表着你的构想被被互联网的核心工作组看见，全球的网络研究者都会读到并且讨论它。
这证明了你的构想足够出色，已经获得了很高的认可。
再往后是一些综述、观念讨论、经验总结类的文档，或者一些已被淘汰的旧文档，含金量偏低。
在计算机学界，能在标准类RFC或者实验性RFC留下名字的人，那可就是名扬一方的大佬了。
特别是如果能成为标准类RFC，成为定义整个互联网底层规则的协议，那说是载入技术史都不为过。
第291章 伟大的论文
因此听到陆怀民要投RFC时，施耐德教授顿时感到有些不可思议。
眼前这个外系的博士生，居然要投RFC？还整了一篇300页的论文。
这任谁看了心里都有点犯嘀咕。
因此施耐德教授拿起陆怀民的论文，原本打算粗略看一看，想看看陆怀民究竟捣鼓了个什么玩意，竟然敢大言不惭地说投RFC。
毕竟隔行如隔山。
陆怀民在精密测量领域做出了一些成绩，确实在学生中很厉害。