本文共 1300 字，大约阅读时间需要 4 分钟。
最近在做一个小项目算是模拟了FTP文件传输的过程，在这中间遇到了一些问题，今天就来总结一下这些问题顺便提下解决的办法。
（1）客户端在与服务器建立连接后且在传输过程中，若客户端中止后服务器挂掉。
（2）文件在传输到一半中止后，再次传输，如何传输（即断点续传问题）。 （3）如何实现类似百度云的秒传功能。 （4）在实现并发后，若有成千上万个用户同时下载同一个文件时，如何处理。第一个问题：
首先，为什么在文件传输到一半的时候关掉客户端服务器会挂掉，终归原因是在于我在设计的时候是单方面一直发送，另一方面一直接受，若是两端都正常倒也没什么问题，但若某接受方突然挂掉那么就会导致发送方一直在send()所以进而就导致发送方也挂掉了。 第二个问题： 断点续传如何解决，断点续传的问题本质在于再次启动时并不知道上次文件传输到的位置，以及那个文件是不完整文件。解决这两个问题断点续传也就解决了。 第三个问题： 要解决第三个问题，就必须了解真正的秒传是怎样实现的，也就是并非真实的去上传，而是服务器端在已有资源的前提下为你提供了一个访问该资源的新接口，看似秒传，实则没传。 第四个问题： 很显然，若是访问量一旦飙升特别是对于同一文件，若是并发对其读取且发送是没法实现的。问题本质在于，如何解决多用户同时对于磁盘的某一区域的同时访问。 （1）原因分析出来后解决就容易多了，既然是因为发送端不知道接受端挂掉而导致的，那么解决办法也是不唯一的。
①最简单的解决办法就是接受一波数据就像发送端回复一声，倘若挂掉自然会给发送端的recv()返回值必然是0，这样就可以解决这个问题了。
（2）解决这个问题方法也不唯一，不过在这里我就只提一种解决方案。
那就是通过类似操作系统上对于一个打开文件的处理，也就是会去产生一个中间文件。借由这种思路可以在一开始文件传输时，接收方在创建该文件时给其增添后缀标识其为一个未传输完的文件。例如:a.c.tmp运用.tmp去标识，传输完成后再去掉后缀名就ok了。如是挂掉重启，就去找带有.tmp后缀的文件将其文件大小发送给发送方，便可继续正常接受了。 （3）解决秒传我这目前只有一个思路，就是通过MD5将服务器上所有资源都处理一遍，形成一种Key_Value的映射关系，若是上传的Key值可以查到，则给用户提供一个软连接，可以让其访问，便解决了秒传这个问题。当然这并非完全解决，若是用户是以只读的方式使用该资源倒还罢了，若是要修改资源那便要加入写时拷贝的操作了。
（4）针对于第四个问题，目前也只有一个思路，就是类似内存池的处理一样。一次性拿到操作系统相应资源，由用户去控制分配。同样适用于这里的问题。之后有时间我再详细的写一篇博客，针对于这最后这一个问题，这里就提一下。
转载地址：http://xisnb.baihongyu.com/