FTPWebRequest上传文件只会上传两个文件!

发布于 2024-08-06 12:39:09 字数 153 浏览 10 评论 0 原文

您好,我正在使用 WebRequest 的异步成员将文件上传到 IIS ftp 服务器。

我可以成功上传两个文件。然而,第三个文件上的 BeginGetResponse 永远不会调用我的回调例程!

欢迎任何想法吗?

谢谢,

约翰

Hi I'm using the aynchronous members of the WebRequest to upload files to an IIS ftp server.

I can upload two files with success. However BeginGetResponse on the third file never calls my call back routine!

Any Ideas welcome?

thanks,

john

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

满意归宿 2024-08-13 12:39:09

一些想法:

  • 同步发出请求,看看问题是否消失。如果没有,则开始仔细查看第三个文件(是 HUUUUUUUUUGE 吗?)
  • 确保您明确调用 FtpWebRequest.EndGetResponse() 在回调处理程序中,然后对响应调用 Close()。否则,您将面临保持连接打开的风险,并且可能会遇到客户端、服务器或代理连接限制。
  • 如果您已经在执行这些操作,请安装网络嗅探器,例如 网络监视器 3.3 并查看线路上实际发生的情况。您将能够在那里看到任何错误。
  • 如果您发现错误,请跟踪它们。如果您从未真正看到第三个请求通过网络传输,请将客户端连接限制视为罪魁祸首。如果您看到第三个请求通过网络,但没有响应,请查看服务器问题,例如在 M 秒内限制来自同一客户端的 N 个请求,并尝试在每个请求后添加延迟,看看是否可以避免这种情况。

A few ideas:

  • make the requests synchronously and see if the problem goes away. if not, then start looking closely at that third file (is it HUUUUUUUUUGE?)
  • make sure you're explicitly calling FtpWebRequest.EndGetResponse() in your callback handler, and then calling Close() on the response. Otherwise you'll risk leaving connections open and perhaps bumping up against client, server, or proxy connection limits.
  • if you're already doing those things, install a network sniffer like Network Monitor 3.3 and see what's actually happennig on the wire. You'll be able to see any errors there.
  • if you see errors, track them down. if you never actually see the third request go over the wire, look at client connection limits as the culprit. If you see the third request go over the wire, but no response, look at a server issue like throttling N requests from same client within M seconds-- and try putting in a delay after each request to see if you can avoid this.
简单气质女生网名 2024-08-13 12:39:09

感谢您的回复。我发现我的问题出在 ServicePoint.Connection.Limit 上,

我将此值增加到 4 并开始使用同步方法。我的 FTP 东西现在可以根据我的需要上传文件。

然而,尽管我可以验证我的文件是否完好无损地到达服务器,但流上的 Close() 方法大多数时候会抛出一个 Web 异常,抱怨连接已关闭。

我尝试过 KeepAlive,但只减少了大约 10%(非常粗糙)的传输异常。

我忽略了这些错误,因为我能够确认发送的字节数==文件总字节数,但这不是绅士风度。

我不太确定如何解决这个问题;我花了几天时间在谷歌上搜索,发现有人有类似的问题,但没有真正的答案。

目前我必须继续我的项目的其余部分,因为时间很短,如果您对如何防止底层连接关闭有任何想法(我猜这是控制通道丢失),我将不胜感激见解。

约翰.

Thanks for your response. I discovered that my issue was with ServicePoint.Connection.Limit

I increased this value to 4 and started using the Synchronous methods. My FTP stuff now uploads files as I require.

However though I can verify that my files reach the server intact The Close() method on the stream most of the time throws a web exception complaining that the connection was closed.

I've tried KeepAlive but only reduced the exceptions for about 10% (very rough) of the transfers.

I ignore the the errors as I am able to confirm that the bytes sent == the file total bytes but it is not gentlemanly.

I'm not really sure how to get round this; I spent days googling and found folk with similar issues but no real answers.

For the time being I have to continue with the rest of my project as time is short, If you have any ideas as to how to prevent the underlying connection from closing (I am guessing it's the control channel that drops) I'd appreciate your insights.

John.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文