开发日志－－文件传输系统之技术细节

       因为我们起用了断点续传的手段，大概的方式应该是这样的，客户机首先通过命令socket从服务器中得到文件的长度信息（Socket有两种，命令和数据），然后再产生了一堆工作线程，如五个，然后建立一个数据socket，使工作线程得以通过数据socket对服务器进行联接。
      客户端使用线程池的可行性：假如客户端打开最高十个任务，每个任务最多10个线程来进行数据传输。这也就是说最高将有100个线程在工作，按默认的堆栈2M来计算则消耗200M内存之多。当然，这方面我不一定会给它这么多内存，一般我可能只提供100K的堆栈，也就是说最高需要10M吧。虽然不是很多，但如果用户选择了几百个或更多的文件进行传输时就会带来一定的不利影响，因为每一个线程的摧毁后，又产生一个新的线程，做了大量的无用功。
      在服务器启动时，我将使用两个完成端口，一个命令，一个数据，它们都有自己的socket。每当命令socket收到一个新任务时，就通知数据完成端口让N个工作线程建立或唤醒。
线程池的检查：如果发现线程的数量不够时，我将增加三分之一的线程数量（总数不能超过200），如果发现池中的空闲线程超过工作线程时，开始减少空闲线程的数量，使之降低到工作线程的三分之一的数量。
在开发过程中，有很多因素让我不得不降低了模块的独立性，如之后的任务标识。像一般的线程池之类的，可能就开始与某个功能相关了。
      任务标识，在断点续传中，一个任务是会拥有多个线程的，这些线程与其它任务的线程的职责不同但又处于同一环境中，这时我可以使用要下载的文件名的指针来作为标识。我在线程里设置一个标识，同时在池里做一个标识链表，线程定时去检查所属的任务是否已经被停止了，如果已经停止，将使其进入睡眠状态，同时保存进入睡眠的时间。池子定时检查每个任务线程睡眠的时间，如果超时，则将其卸下当前的任务，使其变成空闲线程。
      上述方面的定时器我暂时选用多媒体定时器，而不是选用精度更高的硬件中断，DDK以后再说吧：）。经过与使用GetTickCount（）的值来进行测试，延迟基本可以忽略不计。
       文件缓冲， 在传输或接收比较大的文件数据时，因为系统不可以在很短的时间内将所有的数据全部送出或接收完毕，如果我们不在内存做一个缓存，则对硬盘的读写将非常的频繁，无形中降低了机器的性能和服务器的处理量。竟然文件缓冲是必须的，这就给了我两个选择，第一个是整个系统的缓冲区是多大，第二个是每个任务可以得到多大的缓冲区。
       下面讨论它们的优缺点，第一种的优点在于缓冲区大小是可知的，对于任务量不多的情况下，速度可能非常快（假设对它们来说有充够的缓冲），但缺点也是很明显的，只要任务量（文件也比较大）一多，性能可能马上降低（得不到足够的缓冲）。第二种的优点在于我们很容易给予其足够的缓冲，在内存可用的情况，速度将非常快，但缺点是，不容易控制，缓存会随着任务量而增长。