今天终于把文件传输部分改得几乎能正常传输完整个文件了，试了2KB、84KB、2MB三个文件，都没问题，其中2MB的是个Rar文件，能正常解压缩，说明应该是没有一个字节是错的了，而且速度在局域网内也基本在一个可接受的范围内。
昨天传文件的时候，还一直会丢失些数据，反正发送端是应该没什么错的，老老实实把整个文件的内容都读出来，然后一次1KB左右发出来，可是接收端总是收到不在期望内的数据，或者就是收到几个数据包后，就再收不到什么数据了。当时我还怀疑是不是因为发送得太快，但又觉得加个延时进去明显不太合理；又怀疑是不是收到数据包的顺序可能跟发送的顺序不一致，所以还试了试给数据包加入序号，但这个举措明显解决不了前面提到的两个问题。昨天可谓是毫无头绪，连猜带蒙地整了一天，结果就是证明了那些想法都是不可行的。
今天也算是灵机一动，想到了曾经看到过http下载文件，多线程下载时，就是可以指定下载文件的偏移量，于是我想，我也这样做，而且每次只发送一小点，接收端收到后再请求下载另外一部分，这样就直到把整个文件下载完，于是，果然可以完整地传输完整个文件了，虽然代码写得很dirty。现在想起来，在这样的策略下，要让这个操作支持断点续传和多线程下载也不是很麻烦的事了。
搞定了文件传输问题后，感觉心情一下舒畅了很多，换了另外一个工具的维护工作，要增加一个新功能，当时我估摸着可能要花些时间，于是跟那同事说要2天工作量。也不知道是不是心情好的缘故，不到3个小时就几乎搞定了，同样代码写得很dirty，而且这个工具最初代码是另外一个已经离职的人写的，他的代码风格跟我的路数不一样，我在这样的基础上进行维护，代码看着要多别扭就有多别扭。不过这只是个小工具，功能很弱很少，所以这些都不用太关注，要求实现的功能做了就行了。
之后又看了一会儿dot的user guide，开始还以为用它来画流程图很符合格式化后流程图的显示的形式，只要用一组比较清晰简洁的语法，直接可以生成一张图片，但是后来发现我这工具中对流程图的可控性要求比较高，不但要求显示，而且要求一定程度的编辑的能力，即需要能随时方便地知道某个坐标下是哪个节点，或者某个指定的节点在哪个位置，但是今天看了dot的只是直接输出成某种图片的格式，可能比较复杂。现在想想还是有可能知道是，比如SVG、PS之类的格式dot也是直接支持输出的，这类格式的文件其实是文本内容，应该保存有这类节点标识和位置信息的映射关系的，只不过再要解析它们，复杂性如何就不得而知了。
支付宝扫一扫
微信扫一扫