TcpClient 带宽估计

发布于 2024-10-08 01:33:12 字数 110 浏览 2 评论 0原文

我想使用 TcpClient 创建带宽估算工具。我遇到的问题是,我想在预定义的时间内执行测量(而不是预定义要传输的缓冲区数据长度)。如果我使用循环(重复传输小块数据),会不会降低性能(手动碎片与自动碎片)?

I want to create bandwidth estimation tools using TcpClient. The problem im having is, I want to perform measurement in predefined time (instead of predefine buffer data length to transfer). If i use loops(transfer small chunks of data repeatedly), wouldnt that slow down the performance(manual fragmentation vs auto fragmentation)?

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

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

发布评论

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

评论(1

再浓的妆也掩不了殇 2024-10-15 01:33:12

这取决于您是否禁用 Nagle 算法。如果你这样做,那么是的,你自己就会把事情变得支离破碎。如果不这样做,您就不太可能实现您的目标 - 因为当您认为数据可能实际上时,数据可能不会被写入......除非连接的另一端发回最终的“确认”当然。

我建议您使用一个较小的样本来计算出大概的速度,然后基于此创建一个较大的样本,预测需要多长时间。无论如何,您都需要测量时间 - 这不像您会达到精确预定义的时间 - 所以它不会产生太大的差异。无论如何,你总是可以在某种程度上调整大小 - 我预计你最终会发送大量数据包,除非网络非常慢,所以如果你决定只发送 200K 而不是 300K,这应该没有太大区别。

当然,这可能听起来像您最初的建议 - 但我只是谈论每次调用发送“相当大”的数据块......比如说 16K。 (无论如何,比数据包大小大得多。)这不会对碎片产生太大影响,但仍然允许您在进行时进行一些调整。我不建议您发送非常小的数据包。

It depends whether you disable the Nagle algorithm. If you do, then yes, you'll be fragmenting things yourself. If you don't, you're unlikely to achieve your aim - because the data may not actually be written when you think it is... unless the other end of the connection sends back a final "ack" of course.

I would suggest you use a smallish sample to work out the rough speed, and then create a larger sample based on that, predicting how long it will take. You'd need to measure the time anyway - it's not like you're going to hit an exact predefined time - so it shouldn't make too much difference. You can always adjust the size as you go to some extent anyway - I'd anticipate that you'd end up sending plenty of packets unless it's a really slow network, so if you decide half way through to only send 200K instead of 300K, that shouldn't make much difference.

That may sound like your original suggestion, of course - but I'm only talking about sending "pretty large" chunks of data per call... say 16K. (Much bigger than the packet size, anyway.) That shouldn't affect fragmentation much, but will still allow you to tweak things somewhat as you go. I wouldn't advise you to send tiny, tiny packets.

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