才完全搞懂在encode的时候几个参数是么起作用的

　　昨天还算可以，跌跌撞撞地终于把怎样恢复单个数据块的代码给搞定了，哎，其实也没算自己搞定了代码，只不过知道怎样调那几个参数怎样输出罢了，不过搞定之后发现还是裸机有点乱，像乱嵌入了一些代码在一堆不懂的代码当汇总而这刚好能work而已，然后今天搞了一上午终于明白了

 

我是这样子做试验的，试验的对象是一个192kB的文本，这个文本大致上是由6个32k的段落组成的，每个段落有512行，每一行大小是64B，六个段落分别是数字1-6，但是在第一段里面有一些行被改掉了，这样就可以看出是怎样work的了

 

比如我现在跑一个encoding，参数是k=6，m=2，wordsize=8，packetsize=64，buffersize=1024（这个只是这样设定，但是在代码当中是会帮你调整的，因为不够大）

wordsize表示我文本当中多少个数字去组成一个word？这个word是它EC里面用到的术语，很多的讲述EC的教程为了简化都是将w=1，这里的话我设定一个常用的数值8，然后packet这个单位很重要，这个单位的设定是会影响到最终encoding之后出来的数据的，当然在我的例子当中就表现为，比如packetsize是32和64的时候，test_data_1的数据时不一样的。然后packetsize就是意味着，我每一次编码，是不会直接拿整个原始数据块去编码的，我每次拿k个“packet”，每个packet是什么?就是packetsize个word，所以联系我前面所设定的参数，我这里的packetsize设置为64，那么我现在每一个packet的大小就是：（这个是int的大小）4*8*64=2048B，由于每一行的大小是64B，所以就是：第一次编码子过程中，拿出6*2048B 大小的部分（当然是从头开始，对应的，在我的文本里面，就是等于拿出了前192行），然后给data segment分配去，按照顺序轮流分配32行，那么这一次编码的子过程，显而易见的，需要到读入6*2k=12k那么大的数据，所以buffersize就是12k，那么这一次完了之后呢ok，继续下一次编码的子过程，所以第193-224这32行数据，就成为了第一个data segment的第二个组成部分（当然的，最后这6个数据块每个大小都是32k，原始文件大小的六分之一），然后如此循环下去。

 

然后在编码一次之后，它会生成一个meta文件，里面记录了源文件的文件名，文件大小，k，m，w，packetsize，buffersize，这些值，最后还有一个readins这个数值，其实就似乎表示，如果每次我已经设定了只读入buffersize这么多的数据，那么我需要读多少次才能读完原始文件，这个没有什么实际作用，只不过在解码的时候，用一个while循环来控制次数而已，因为在decode的过程中，其实也是相当于encode的一个反过程，比如datasegment1不见了，那么我每次都从其他数据快和校验快的头部开始拿一些数据出来进行计算，就这样而已

 

 

所以这次的话，纠正了几个很傻逼的以前认为是正确的关键问题，当然我以前一直认为data segment对于源文件是水平分割的，其实不是的，当然应该也可以，改变下矩阵，不过这样不知道还能不能解码，然后要注意这个packetsize应该作为我的实验代码里面的一个全局不能变的量，因为是直接决定了源文件是怎样被分隔的，听说1024会比较好，不知道呢，反正一定不能变

 

然后下个问题就是想清楚到底在update的时候这个从client端过来的offset应该怎样指定了， 弄清这个问题之后就能很快地吧之间写的传送文件的代码和EC的代码合成起来了，当然我现在初步的想法还是将这个识别offset应该是去哪里的操作交给proxy server，反正客户端就直接指定写了源文件的那里就好了，规定了w和packetsize之后这个由client library来计算下应该是很快的事情了

 

好吧，就这样

 

OH！！！！！！！！！！　　FUCK ME ！！！！！！！！！！！！

我的基础啊！哎。。。。

原来cauchy 的方法就是原原本本地分割的。。。。。。。。fuck！！！！！！！！

就用它了，不过算了，也算走了一趟经典的reed solomon吧