上传非常大（> 1GB）文件的建议

发布于 2024-07-25 19:52:28 字数 471 浏览 3 评论 0原文

我知道 SF 中存在此类问题，但它们非常具体，我需要一个通用的建议。我需要一个用于上传大小可能超过 1 GB 的用户文件的功能。此功能将是应用程序中现有文件上传功能的附加功能，可满足较小的文件需求。现在，这里有一些选项

使用 HTTP 和 Java applet。以块的形式发送文件并在服务器上将它们连接起来。但如何限制n/w。
使用 HTTP 和 Flex 应用程序。它比小程序与浏览器兼容性和兼容性更好吗？还有其他环境问题吗？
使用 FTP 或 SFTP 而不是 HTTP 作为更快上传过程的协议

请建议

。此外，我必须确保此上传过程不会妨碍其他用户的任务，或者换句话说，不会占用其他用户的黑白。有什么机制可以在 n/w 级别上完成来限制此类进程？

最终客户希望将 FTP 作为一种选择。但我认为以编程方式处理文件的答案也很酷。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

热鲨 2024-08-01 19:52:29

使用您想要的任何客户端语言（Java 应用程序、Flex 等），并使用 HTTP PUT（无 Flex）或 POST 推送到服务器。在服务器端 Java 代码中，调节输入流循环中的字节流。一个粗略、简单的示例片段，将带宽限制为不超过平均 <= 10KB/秒：

InputStream is = request.getInputStream();
OutputStream os =  new FileOutputStream(new File("myfile.bin"));
int bytesRead = 0;
byte[] payload = new byte[10240];

while (bytesRead >= 0) {
    bytesRead = is.read(payload);

    if (bytesRead > 0) 
        os.write(payload, 0, bytesRead);

    Thread.currentThread().sleep(1000);
}

（复杂性越高，可以更准确地调节单流带宽，但在考虑套接字缓冲区等时，它会变得复杂。“足够好”通常已经足够好了。）

我的应用程序执行与上面类似的操作 - 我们同时调节 up (POST 和 PUT) 和 ( GET）下行带宽。我们每天接受数百 MB 的文件，经测试最大可达 2GB。（超过 2GB 还需要处理烦人的 Java int 原语问题。）我们的客户都是 Flex 和 curl。它对我有用，对你也有用。

虽然 FTP 非常出色，但您可以通过使用 HTTP 来避免许多（但不是全部）防火墙问题。

Use whatever client side language you want (a Java App, Flex, etc.), and push to the server with HTTP PUT (no Flex) or POST. In the server side Java code, regulate the flow of bytes in your input stream loop. A crude, simple, sample snippet that limits bandwidth to no faster than an average <= 10KB/second:

InputStream is = request.getInputStream();
OutputStream os =  new FileOutputStream(new File("myfile.bin"));
int bytesRead = 0;
byte[] payload = new byte[10240];

while (bytesRead >= 0) {
    bytesRead = is.read(payload);

    if (bytesRead > 0) 
        os.write(payload, 0, bytesRead);

    Thread.currentThread().sleep(1000);
}

(With more complexity one could more accurately regulate the single stream bandwidth, but it gets complex when considering socket buffers and such. "Good enough" is usually good enough.)

My application does something similar to the above--we regulate both up (POST and PUT) and (GET) down stream bandwidth. We accept files in the 100s of MB every day and have tested up to 2GB. (Beyond 2GB there is the pesky Java int primitive issues to deal with.) Our clients are both Flex and curl. It works for me, it can work for you.

While FTP is great and all, you can avoid many (but not all) firewall issues by using HTTP.

回复收藏 0 原文