[原]诞生!fileTMS分布式文件传输系统

    这个是才做好的管理客户端界面.

    说说需求,服务器有很多台,这里DEMO程序只用了2台来测试并发.上传文件的时候,不再使用繁琐的FTP,而是一次性传输到所有服务器去.要求安全,可靠.

    服务器端使用boost C++库的boost::asio,异步完成端口proactor模式,console界面,相同服务端代码,分别编译2次为目标平台(windows和linux),一个fileTMS.exe 一个 fileTMS.为了简单起见,程序放在哪个目录,接受文件的时候就直接存入当前目录.

    以上看得到界面的是客户端界面.net2.0框架,文件多选之后,就开一个backgroundworker,并发上传,为了确保可靠性,线程工作是排它模式,也就是说是 文件数*服务器数 这么些操作对应少量的线程逐一执行,不存在访问冲突.每个线程记录TLS到本地文件,形成索引,以便断线续传.

    文件传输的IO缓冲区定义为 [密码/n文件名/n文件长度/n/n/n文件实体流] 这种形式,改FTP的数据端口+控制端口的模式为单一的端口模式.

    .net使用clickonce发布到内部网,供非技术人员使用.那么就涉及到泄密问题,一旦泄密,任何人都可以上传文件到服务器,甚至恶意代码和脚本.那么解决方案是:

    1.文件服务器端管理密码

1.1密码由安全数据库存储,所有服务器通过freetds(因为历史原因,这里使用的是MSSQL服务器)取到密码,这个密码,由客户端统一在"执行口令"界面上输入,.net本身因为安全问题,将不存储任何本地密码验证模块.

        1.2内部因素,就是非技术人员私下上传了一个精心构造的文件,无非是想挂马,那么服务器会对文件内容进行扫描,检查sqlinjection特征,排除渠道通过密码来识别,比如下放的普通密码是123,这个密码对应的是需要服务器过滤,那么如果密码是123456,服务器就直接忽略sqlinjection特征检查了,因为这123456是开发人员上传的文件,他们的程序文件里面通常都含有各种sql.

    2.文件服务器计划任务

        考虑到可能的SYN攻击或者一般的SYN扫描,所有文件服务器在上班时间范围内才工作(监听端口).除此之外,不再监听响应的端口.

    可能存在的问题:/n标志的识别问题,黑客SYN包扫描端口的后继处理.