太诡异了,居然TCP也会丢包啊~~哪位牛人来解释一下!

BORLANDSUN 2011-08-21 11:22:56
在写一个客户端,通过TCP协议实时接收远程的视频录播服务器传来的视频流。今天把图像调出来了,但是断断续续的,不很流畅。统计了下结果,丢包率大约在15%左右。
客户端用TClientSocket接收的,接收部分放在单独的一个线程中,处理部分也放在单独的一个线程中。CPU占用率很低,不到5%,真是怪呀。似乎线程的负载都不大,但丢包的确是发生了。
又作测试,把服务端的码流调低约1倍,这时客户端就基本上不丢包了,这是怎么回事呢?我猜是不是客户端的缓冲区太小了,给塞满了还是怎么回事。但如果塞满了,服务端应该会等我把数据取走才会继续发,也不应该丢包啊。不然他那边一直发,这不就变成UDP了吗。奇怪。
我把接收部分大致的代码也帖出来:

DWORD WINAPI OnFrame(PVOID pvParam)
{
static ReceivedLen = 0;
static char ReceiveBuffer[MaxBufLen];
while(true)
{
int Len = sktClient->Socket->ReceiveBuf(&ReceiveBuffer[ReceivedLen], 1024000 - ReceivedLen);
if(Len > 0)
{
ProcessData(CmdData, pos); // 这个处理又是在另一个线程中做的
}
}
}
...全文
1038 11 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
11 条回复
切换为时间正序
请发表友善的回复…
发表回复
BORLANDSUN 2011-08-24
  • 打赏
  • 举报
回复
[Quote=引用 9 楼 zhouzhangkui 的回复:]

用抓包工具看看,看实际收到的是不是 你发出的总和 ,这样就知道问题在哪里了
[/Quote]
那边发包不是我控制的,所以不知道到底发多少
手头没有抓包工具,但从任务管理器中看,画面卡住的时候,网络流量的确是下去了。
BORLANDSUN 2011-08-24
  • 打赏
  • 举报
回复
问题找到了,还真是视频服务器的问题。唉,那帮鸟人们,在外企拿那么高的工资,写这么烂的代码,换我早自杀了。
大学里老师没教好啊,放出来这样一帮渣子来到社会上,毒害人类!
结帖,放分!
  • 打赏
  • 举报
回复
[Quote=引用 5 楼 my_love 的回复:]
我想说的是,这个丢包十有八九不是在网络传输时丢的,而是服务器压根就没有发出去。
[/Quote]

正确,应该是TCP流量控制造成的。
土著巫师 2011-08-23
  • 打赏
  • 举报
回复
  楼主,在TCP上传输实时视频数据,你也太牛了吧!不好意思,问你一个小问题:有哪家成熟的视频网站或视频服务商是用的TCP传输数据?我的答案是没有!视频数据天生就是要用UDP传输的!

  如果是局域网环境,TCP可能勉强能用,这还要取决于程序实现的如何,反正我是没这么干过。

  说一点基本认识吧:之所以视频数据要用UDP协议处理,一个原因就是因为视频数据量很大,要快,另一个原因是因为视频数据丢帧影响相对有限,因为前一帧丢了,后一帧补上了不影响视觉效果,只有连续的丢帧才会有问题(如果你传一个文件哪怕丢了一个字节,后果是什么不用我来说,所以FTP是建立在TCP协议上工作的,所有用UDP传输文件的都要程序员引入流控制和丢包处理,相当于自己在应用层实现了部分TCP协议功能);另一个原因,UDP的组播特性设计就是为视频服务设计的:数据只发送一次,大家都收到,想想看同一个子网上不可能100个用户,发送100次同样的视频数据吧?

  简单聊几句,希望对楼主在总体设计(不是实现)思路上有帮助。:)
aranjuze 2011-08-23
  • 打赏
  • 举报
回复
是不是带宽的原因啊!
BORLANDSUN 2011-08-23
  • 打赏
  • 举报
回复
[Quote=引用 4 楼 boyla 的回复:]

  楼主,在TCP上传输实时视频数据,你也太牛了吧!不好意思,问你一个小问题:有哪家成熟的视频网站或视频服务商是用的TCP传输数据?我的答案是没有!视频数据天生就是要用UDP传输的!

如果是局域网环境,TCP可能勉强能用,这还要取决于程序实现的如何,反正我是没这么干过。

说一点基本认识吧:之所以视频数据要用UDP协议处理,一个原因就是因为视频数据量很大,要快,另一个原因是因为视频数据……
[/Quote]
这位大哥:
1. 我不牛,那家提供视频服务器的公司提供的的确是TCP接口
2. 你的“小问题”在1.我已经回答了
My_Love 2011-08-23
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 borlandsun 的回复:]

引用 1 楼 my_love 的回复:
看SendBuf的返回值是-1,则过会而重发。
要不设成阻塞式,就不用管返回值。

服务端对我来说是黑盒,不知道里边的运作模式。
引用 2 楼 jonix 的回复:
排除网络原因以外,一般都是程序自身的问题。

这话说得太精辟了,但对于分析解决问题似乎没有帮助。
[/Quote]
我想说的是,这个丢包十有八九不是在网络传输时丢的,而是服务器压根就没有发出去。
周药师 2011-08-23
  • 打赏
  • 举报
回复
用抓包工具看看,看实际收到的是不是 你发出的总和 ,这样就知道问题在哪里了
Jonix 2011-08-22
  • 打赏
  • 举报
回复
排除网络原因以外,一般都是程序自身的问题。
My_Love 2011-08-22
  • 打赏
  • 举报
回复
看SendBuf的返回值是-1,则过会而重发。
要不设成阻塞式,就不用管返回值。
BORLANDSUN 2011-08-22
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 my_love 的回复:]
看SendBuf的返回值是-1,则过会而重发。
要不设成阻塞式,就不用管返回值。
[/Quote]
服务端对我来说是黑盒,不知道里边的运作模式。
[Quote=引用 2 楼 jonix 的回复:]
排除网络原因以外,一般都是程序自身的问题。
[/Quote]
这话说得太精辟了,但对于分析解决问题似乎没有帮助。
在Windows 10或Windows 11操作系统中,用户经常遇到共享打印机时出现的一系列错误代码,这些错误代码可能阻碍打印机共享功能的正常使用。常见的错误代码包括0x00000057、0x00000709和0x0000011b,这些代码通常指出了不同的问题,比如权限不足、服务未运行或配置错误等。除此之外,还有一些故障提示如“连接失败”或“内存不足”,这些都可能影响到打印机共享的稳定性。 要解决这些故障,首先要确保打印机已经正确地连接到网络,并且在需要共享的电脑上进行了设置。确保打印机驱动程序是最新的,并且在共享设置中没有错误配置。对于权限问题,需要检查网络上的用户账户是否具有足够的权限来访问共享打印机。同时,也要确保打印机服务正在运行,特别是“Print Spooler”服务,因为这是打印机共享服务的核心组件。 在某些情况下,问题可能与操作系统的更新有关,如升级到最新版的Windows 10或Windows 11后可能出现的兼容性问题。这时,可能需要查看微软的官方支持文档来获取特定的解决方案或更新。 对于错误代码0x00000057,这通常是由于没有足够的权限来访问网络打印机或其共享资源,解决方法是确保网络打印机的权限设置正确,包括在组策略中设置相应的访问权限。而0x00000709错误可能是由于打印机驱动问题或打印机端口配置错误,可以尝试重新安装或更新打印机驱动来解决。至于0x0000011b错误,这往往是因为打印机队列服务的问题,检查并重启“Print Spooler”服务通常是解决这类问题的常见手段。 至于“连接失败”或“内存不足”这类故障,通常与客户端和打印机之间的网络连接以及打印机本地资源的使用情况有关。检查网络连接,确保打印机所在的网络段没有故障或中断。同时,如果打印机的打印队列长时间得不到处理,可能导致内存不足的情况,这时可能需要清理打印队列或增加打印机的内存配置。 为了帮助用户更快速地解决这些问题,市面上出现了各种打印机共享错误修复工具。这些工具往往通过预设的修复程序来自动检测和修正打印机共享中常见的问题。它们可以快速检查打印机驱动、网络连接以及共享设置,并且能够提供一键修复功能,大幅减少了用户自行排查和解决问题的难度。 然而,在使用这些修复工具之前,用户应确保这些工具的来源是安全可靠的,避免因使用不当的修复工具而引发其他系统安全或隐私问题。用户可以到官方平台或者信誉良好的软件提供商处下载这些工具。通过细心检查打印机的共享设置,及时更新驱动程序和服务,以及合理使用修复工具,大多数共享打印机的问题都可以得到有效的解决。

13,871

社区成员

发帖
与我相关
我的任务
社区描述
C++ Builder相关内容讨论区
社区管理员
  • 基础类社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧