最近我发现在我blog上的一篇关于FastDFS客户端的文章被很多人点击过了。我分析了一下（一厢情愿的），可能是因为DFS没有net的客户端吧！后来联系上了FastDFS的作者，证实确实缺乏“官方”的net客户端，正好以前应用过DFS，也写了一个net的客户端，所以就正式贡献出来开源。
此次开源的FastDFS客户端对应着DFS的V1.21版本。从测试和目前的使用情况来看，V1.21已经比较稳定了，大规模的应用已经没有什么大的问题；据从作者处得知的情况，FastDFS的V1.23版本（具体不确定哪个版本，但是肯定是V1.21以上版本。）以上已经更改过“传输协议”，所以暂时的DFS客户端版本不支持；这里也不敢随便向各位保证什么时候会更改客户端，因为下半年事情比较多。但是我用良心保证V1.21的版本绝对问题不大，而且这个客户端对V1.21绝对支持。
DFS的Net客户端使用Net Framework2.0完成，不提供Net Framework1.1版本。从测试情况来看，使用TCP的短链接会频繁的触发net的GC机制，所以增加了“连接池”的功能。DFS体系中的Tracketr的负载平衡也是通过DFS的客户端完成，目前提供的方式为“轮询”机制（Storage的负载平衡通过DFS的服务器端的配置完成），当然为了提高系统的可用性，会在链接失败和线程池中无可用连接池通过短链接作为补偿机制（该补偿机制通常不出现）；在net客户端中增加的BatchUpload方法，这是提供给一个更改版本的FastDFS使用的，从FastDFS官方网站下载的软件中没有此功能（已经和FastDFS的作者联系过，代码也已经提交，不知道是不是已经放进去。）。
查看DFS客户端的朋友可能会发现在客户端中除了一个Upload方法以外没有别的方法，但是FastDFS的服务器端提供了对图片的上传，修改，删除等操作。至于为什么我们没有提供除了upload以外的方法，原因在于：现在Web2.0时代，对于互联网企业，80%的数据都是第一次增加后不会更改的，只有20%的数据会更改，而且一般频繁更改的数据都会放在数据库中或者廉价的存储中，所以对于需要更改的文件，那么我们就让用户再上传一次文件，这种方式更有利的地方是速度快，节省带宽，减少复杂度，而且重复的图片也不会太多，对于存储文件TB级的文件来讲，这些文件的量基本可以忽略不计。
对此已经更改的版本（增加了batchupload功能，增强了DFS的文件管理性），我们已经在考虑将其开源了，因为更改完成后因为工作和时间的问题，到现在都未对其进行测试，所以等测试完毕，我们将对其开源。
最后，为了支持开源，希望各位在使用分布式文件系统时考虑一下国人的劳动成果。
附：
FastDFS：http://code.google.com/p/fastdfs/
FastDFS .Net Client: http://code.google.com/p/fastdfs-net-client/
FastDFS TCP传输协议解析：http://www.cnblogs.com/Seapeak/archive/2010/02/10/1666986.html
