这个题我觉得最重要的,就是要体现“渐进增强”这个思想特点。即规模小怎么干都行,随着要求一点点增多或者差异化的时候,再去一点点加以约束,寻找可行的做法。 越快越好:也要看具体是怎么个快。如果是追求绝对的传输速度,那么就是追究物理层速度和双方的缓存策略。如果是追求差分传输,就要上rsync了。 B是10000台机器:一主多从分发,并且这么大的范围往往是必须用互联网连接的。 绝对不能出错:hash等校验,并且话下的这么死,估计SHA-1都有点不够用。这句话还有个潜台词是“发现错了要有办法”,也就是说还要准备部分验证和部分重传的方案,其实多半也用rsync。 断点续传:如果只是要这个那就太灵活了。 可能出什么样的错误:其实大部分真真正正的传输错误,都在数据链路层就被控制了下来。所以错误往往更多的出在双方——通信一方无响应或意外中止传输,存储空间满,不一而足。 注意错误和设计缺欠并不一样。例如数据储存和处理速度不同步(这个的典型表现就是缓存区欠载或缓存区爆仓)这就是设计缺欠,而不是传输过程中出的错误。
rsync -z, 使用尽可能快的传输线路; bt 或者多播; sha1sum 和/或 gpg 签名校验;(当然,文件很多的情况下对 tar / cpio 包进行签名,这样就需要额外的磁盘空间) rsync;据说 FTP 也可以。HTTP 下载也是支持续传的 传输信道中断、读取/写入被操作系统拒绝(因为权限、磁盘空间/配额、磁盘故障)、系统宕机(电源中断、系统故障等)。
这个题我觉得最重要的,就是要体现“渐进增强”这个思想特点。即规模小怎么干都行,随着要求一点点增多或者差异化的时候,再去一点点加以约束,寻找可行的做法。
越快越好:也要看具体是怎么个快。如果是追求绝对的传输速度,那么就是追究物理层速度和双方的缓存策略。如果是追求差分传输,就要上rsync了。
B是10000台机器:一主多从分发,并且这么大的范围往往是必须用互联网连接的。
绝对不能出错:hash等校验,并且话下的这么死,估计SHA-1都有点不够用。这句话还有个潜台词是“发现错了要有办法”,也就是说还要准备部分验证和部分重传的方案,其实多半也用rsync。
断点续传:如果只是要这个那就太灵活了。
可能出什么样的错误:其实大部分真真正正的传输错误,都在数据链路层就被控制了下来。所以错误往往更多的出在双方——通信一方无响应或意外中止传输,存储空间满,不一而足。
注意错误和设计缺欠并不一样。例如数据储存和处理速度不同步(这个的典型表现就是缓存区欠载或缓存区爆仓)这就是设计缺欠,而不是传输过程中出的错误。