服务器远程预览本地设备视频, 预览多个,打不开视频流

本文介绍了在处理设备与服务器视频预览连接时遇到的EPIPE异常问题。当设备尝试向服务器发送视频数据时,出现EPIPE(32)错误,原因是客户端提前断开了连接。解决方案涉及对errno的详细处理,防止资源泄露。同时,讨论了其他相关错误码,如AGAIN、EWOULDBLOCK、EINTR,并指出recv返回0表示连接已断开。
摘要由CSDN通过智能技术生成

今天,解决一个现场报回来的故障,关于sock 异常处理导致的问题。


现象是设备收到服务器视频预览的命令后,给服务器传视频数据,发送失败,返回EPIPE(32)错误号;

而且本地又是客户端, 正常的逻辑是本地收到服务器的close流命令后,方可关闭预览流连接。

目前,由于设备端对发送返回值处理没有对errno做细节处理,没有去释放本地资源,导致资源泄露。


增加一些ERRNO 普遍返回值介绍,以后长点记性:

EPIPE:由于 client 在服务器返回前主动断开连接,所以服务器在返回时写 socket 收到SIGPIPE报错

AGAIN、EWOULDBLOCK、EINTR与非阻塞 长连接

EWOULDBLOCK用于非阻塞模式,不需要重新读或者写

EINTR指操作被中断唤醒,需要重新读/写

在Linux环境下开发经常会碰到很多错误(设置errno),其中EAGAIN是其中比较常见的一个错误(比如用在非阻塞操作中)。
从字面上来看,是提示再试一次。这个错误经常出现在当应用程序进行一些非阻塞(non-blocking)操作(对文件或socket)的时候。例如,以 O_NONBLOCK的标志打开文件/socket/FIFO,如果你连续做read操作而没有数据可读。此时程序不会阻塞起来等待数据准备就绪返 回,read函数会返回一个错误EAGAIN,提示你的应用程序现在没有数据可读请稍后再试。
又例如,当一个系统调用(比如fork)因为没有足够的资源(比如虚拟内存)而执行失败,返回EA
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值