刚刚拿到这个需求时，为了实现方便（传送文件已经实现，传送文件夹采取压缩的话也只需传送一个文件），计划采取的实现方法是：调用压缩组件，将文件夹压缩成一个文件，传送到另一端；在接收时，解压缩此文件得到文件夹。由此带来的问题是：没有一个免费的压缩文件夹的组件。于是想到的策略是：用shell程序调用dos下的arj.exe压缩。但是由于arj是dos工具，有一个文件名的问题：文件名长度超过8位（中文4位），就会自动截断。针对这个问题：又想了一种很笨的解决办法：将传送前，遍历文件夹，记录所有文件和文件夹名，传送时附带传过去，接收端接收完文件，解压缩后，修改文件名。经过这么一折腾，由一个问题带来很多的头痛的问题。（陷入了怪圈）。
后来经过仔细考虑，觉得用上述方法传送文件夹，有很多的隐患。一：如果文件夹很大或文件很多，发送前的压缩操作需要很长时间，用户可操作性太差；二：由于要压缩文件夹，就需要保存，删除临时文件，如果处理不得当，会错删文件；三：用arj需要修改文件和文件夹名字，改名算法如果不健壮同样是一个隐患。
综合考虑了以后，决定修改传送算法。基本思路是：既然传送一个文件已经实现，传送文件夹的话，无非是在一个连接过程多进行几次传送文件的过程。详细方法描述：发送文件夹之前，首先遍历文件夹，保存每个子文件夹和文件信息（包括文件相对于选中的文件夹的路径，文件大小，文件名）；传送之前，先发送传送请求，附带待传送文件夹的总体信息（文件夹名和文件夹总文件大小），接收端收到请求信息后，保存这些信息，选择保存路径，并发送确认标志符。发送端收到确认标志符，首先传送单个文件的信息（单个文件的大小，文件名）；接收端收到后，保存单个文件大小，在本地创建文件，发送请求发送文件内容标志符。发送端收到后开始发送文件体；接收端开始接收文件体，当保存单个文件大小和接收到的数据相等时，请求发送第二个文件的文件信息，依次下去。直到接收到的数据和总文件信息大小相等。发送接收完成标志符。整个传送过程完毕。
传送过程如下（省略了和服务器端交互过程）：
这样，整个传送文件夹过程就结束了。 当然这个过程可能也不完善，以后再慢慢改进。欢迎大家提出意见！