该帖已经被评为隐藏帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-10-31
客户端 发送请求
服务端得到请求 服务端去读文件 服务端将读到的文件发送给客户端 服务端读取并发送完全部文件后,可以理解为客户端已经完成下载. 如果这期间客户端 中止下载, 那么服务端可以得到客户端的链接断开的信息 当然 这个思路是有误差的, 误差发生在最后时刻. 服务端"读取并发送完全部文件",但是客户端还没有接收到最后发送的那一部分内容时,会出现一点点误差,但是应该可以忽略不计的. |
|
返回顶楼 | |
发表时间:2007-10-31
文件大约有多大........ 可以用下载软件下载么......
|
|
返回顶楼 | |
发表时间:2007-10-31
我怀疑你这个地方有没有try一下
response.getOutputStream().write(data); response.getOutputStream().close(); 还有什么原因会导致客户端还没下完就出故障?突然停电?这是客户端的问题,这个难道还得你们负责啊 |
|
返回顶楼 | |
发表时间:2007-11-01
to myy
引用 try{
InputStream inputStream = new FileInputStream(file); // 以byte流的方式打开文件 d:\1.gif int i=inputStream.available(); //得到文件大小 data=new byte[i]; inputStream.read(data); //读数据 // // 带密码压缩数据 // 不知道这段怎么理解? to inputStream.close(); inputStream=null; }catch(FileNotFoundException e){ err="无法在服务器上获取相关文件!文件不存在."; }catch(Exception e){ err=e.getMessage(); } 这不好理解么? 数据是服务端输出的,在输出前,压缩并加密了一下而已,比如简单一点可以这样: 1.用户 "user01" 请求文件"thedoc.doc"(如: http://.../getfile.jsp?file=thedoc.doc ) 2.getfile.jsp先找到真正的thedoc.doc,并随机生成一个密码"asdfgh"(规则自定义) 3.getfile.jsp用命令行带参数(包括密码"asdfgh")调用rar.exe, 生成临时文件 user01_20071101100505_thedoc.doc.rar(规则自定义) 4.将文件名"user01_20071101100505_thedoc.doc.rar" 和 密码 "asdfgh"存入数据库 5.将文件 user01_20071101100505_thedoc.doc.rar 输出到用户 ... 6.用户下载完成,用 winrar 打开(利用 winrar 验证文件是否完整),发现要密码才能解压,于是必须点“扣费”按钮(同时输入文件名"user01_20071101100505_thedoc.doc.rar"), 后台从数据库根据文件名,取出密码 "asdfgh"显示给用户。 |
|
返回顶楼 | |
发表时间:2007-11-01
try{
response.getOutputStream().write(data); response.getOutputStream().close(); }catch(e ...){ //失败 } 其实,这样就足够了,如果还是出问题,那就肯定是客户端的问题。 你们其实设计思路有问题,应该不是如何保证全部正确发送,这基本是做不到的,因为你不能保证客户端的正确与否,而是要保证客户在出现问题后还能有补救的办法,比如再让他能免费下一次。 |
|
返回顶楼 | |
发表时间:2007-11-01
我以前在一家新闻图片销售公司做的时候,记录客户第一次下载的时间,生成订单,然后在一段时间内是免费下载的。
控制客户端感觉比较难 |
|
返回顶楼 | |
发表时间:2007-11-01
myy 写道 服务端判断不太好做,也很不可靠。
建议这样: 将收费的东西打包压缩并加密码(最好能动态压缩),让别人随便下,但是没法直接用,然后用户必须点击页面的“扣费”按钮,进行扣费,才给出密码(也可以通过邮件发到用户邮箱中) 典型的不考虑产品的做法,对于一些方案总想绕道而行,你这种做法无疑是提高了操作的复杂性 |
|
返回顶楼 | |
发表时间:2007-11-01
lszone 写道 myy 写道 服务端判断不太好做,也很不可靠。
建议这样: 将收费的东西打包压缩并加密码(最好能动态压缩),让别人随便下,但是没法直接用,然后用户必须点击页面的“扣费”按钮,进行扣费,才给出密码(也可以通过邮件发到用户邮箱中) 典型的不考虑产品的做法,对于一些方案总想绕道而行,你这种做法无疑是提高了操作的复杂性 很多共享软件就是这样做的,人家不是做产品么? 再说了,为什么要有麻烦的https,不就是因为http不安全绕道而行么? “提高了操作的复杂性”是在有限条件下,需求要求过高 所必须付出的代价。 |
|
返回顶楼 | |
发表时间:2007-11-02
to fins
引用 客户端 发送请求
服务端得到请求 服务端去读文件 服务端将读到的文件发送给客户端 服务端读取并发送完全部文件后,可以理解为客户端已经完成下载. 如果这期间客户端 中止下载, 那么服务端可以得到客户端的链接断开的信息 当然 这个思路是有误差的, 误差发生在最后时刻. 服务端"读取并发送完全部文件",但是客户端还没有接收到最后发送的那一部分内容时,会出现一点点误差,但是应该可以忽略不计的. response.setContentType("application/octet-stream"); response.addHeader("Content-disposition" , "attachment;filename="+filename+"\""); while(发送文件大小完成) { response.getOutputStream().write(data1); response.getOutputStream().write(data2); ....... } 扣费操作..... response.getOutputStream().close(); 以上的代码思路是不正确的,response.getOutputStream().write();写的数据其实还在服务器端,请求下载文件的触发请求 与 相应文件输出的下载流的操作 应该不是同一个线程,所以,以上的思路在下载过程中就会进行扣费。 |
|
返回顶楼 | |
发表时间:2007-11-02
fins 写道 客户端 发送请求
服务端得到请求 服务端去读文件 服务端将读到的文件发送给客户端 服务端读取并发送完全部文件后,可以理解为客户端已经完成下载. 如果这期间客户端 中止下载, 那么服务端可以得到客户端的链接断开的信息 当然 这个思路是有误差的, 误差发生在最后时刻. 服务端"读取并发送完全部文件",但是客户端还没有接收到最后发送的那一部分内容时,会出现一点点误差,但是应该可以忽略不计的. 关键是“客户端下载是否完成”这个怎么理解?是不是当用户把文件完全保存到本地硬盘之后才算下载完成? 对于Web系统Download文件,是不可能在服务器端完全准确地判断文件是否Download成功了。浏览器都有buffer,对比较小的文件,当OutputStream().write已经结束,也就是数据已经完全发送到客户端,这个时候HttpConnect会关闭,一次Http会话结束,而这时客户端会弹出保存文件的对话框,当客户选择Cancel的时候,服务器端已经完全不知道了。 所以“跟踪 客户端下载是否完成”是无法实现的,除非你自己做ActiveX来下载。 |
|
返回顶楼 | |