socket send fail,txlen=2,send len=-1,errno=(105)No buffer space available
错误
write: No buffer space available write(s, &frame, sizeof(struct can_frame)) 的输出结果为-1;
原因
由于缓冲队列空间不足;
临时办法
echo 1000 > /sys/class/net/can0/tx_queue_len
root@super:/sys/class/net/can1# cat tx_queue_len 10
root@super:/sys/class/net/can1# echo 1000 > tx_queue_len
root@super:/sys/class/net/can1# cat tx_queue_len 1000
最终办法
虚拟机需要接ECU或者应用软件
read/write的语义:为什么会阻塞?
先从write说起:
ssize_t write(int fd, const void *buf, size_t count);
首先,write成功返回,只是buf中的数据被复制到了kernel中的TCP发送缓冲区。至于数据什么时候被发往网络,什么时候被对方主机接收,什么时候被对方进程读取,系统调用层面不会给予任何保证和通知。
write在什么情况下会阻塞?当kernel的该socket的发送缓冲区已满时。对于每个socket,拥有自己的send buffer和receive buffer。从Linux 2.6开始,两个缓冲区大小都由系统来自动调节(autotuning),但一般在default和max之间浮动
已经发送到网络的数据依然需要暂存在send buffer中,只有收到对方的ack后,kernel才从buffer中清除这一部分数据,为后续发送数据腾出空间。接收端将收到的数据暂存在receive buffer中,自动进行确认。但如果socket所在的进程不及时将数据从receive buffer中取出,最终导致receive buffer填满,由于TCP的滑动窗口和拥塞控制,接收端会阻止发送端向其发送数据。这些控制皆发生在TCP/IP栈中,对应用程序是透明的,应用程序继续发送数据,最终导致send buffer填满,write调用阻塞。
一般来说,由于接收端进程从socket读数据的速度跟不上发送端进程向socket写数据的速度,最终导致发送端write调用阻塞。
而read调用的行为相对容易理解,从socket的receive buffer中拷贝数据到应用程序的buffer中。read调用阻塞,通常是发送端的数据没有到达。