Failed to receive data

[v587xpt]

系统版本：Ubuntu 22.04.4 LTS
安装方式：LInux构建
构建成功后运行：

root@proxy:/home/system_install_package/PaddleOCR-json/cpp# LD_LIBRARY_PATH=$LIBS ./build/bin/PaddleOCR-json -models_path="/home/system_install_package/PaddleOCR-json/cpp/.source/models" -config_path="/home/system_install_package/PaddleOCR-json/cpp/.source/models/config_chinese.txt" -port=8484 -addr=any
PaddleOCR-json v1.4.0
Load config from [/home/system_install_package/PaddleOCR-json/cpp/.source/models/config_chinese.txt] : det_model_dir set to /home/system_install_package/PaddleOCR-json/cpp/.source/models/ch_PP-OCRv3_det_infercls_model_dir set to /home/system_install_package/PaddleOCR-json/cpp/.source/models/ch_ppocr_mobile_v2.0_cls_inferrec_model_dir set to /home/system_install_package/PaddleOCR-json/cpp/.source/models/ch_PP-OCRv3_rec_inferrec_char_dict_path set to /home/system_install_package/PaddleOCR-json/cpp/.source/models/dict_chinese.txt. 
---    fused 0 elementwise_add with relu activation
---    fused 0 elementwise_add with tanh activation
---    fused 0 elementwise_add with leaky_relu activation
---    fused 0 elementwise_add with swish activation
---    fused 0 elementwise_add with hardswish activation
---    fused 0 elementwise_add with sqrt activation
---    fused 0 elementwise_add with abs activation
---    fused 0 elementwise_add with clip activation
---    fused 0 elementwise_add with gelu activation
---    fused 0 elementwise_add with relu6 activation
---    fused 0 elementwise_add with sigmoid activation
---    fused 0 elementwise_sub with relu activation
---    fused 0 elementwise_sub with tanh activation
---    fused 0 elementwise_sub with leaky_relu activation
---    fused 0 elementwise_sub with swish activation
---    fused 0 elementwise_sub with hardswish activation
---    fused 0 elementwise_sub with sqrt activation
---    fused 0 elementwise_sub with abs activation
---    fused 0 elementwise_sub with clip activation
---    fused 0 elementwise_sub with gelu activation
---    fused 0 elementwise_sub with relu6 activation
---    fused 0 elementwise_sub with sigmoid activation
---    fused 0 elementwise_mul with relu activation
---    fused 0 elementwise_mul with tanh activation
---    fused 0 elementwise_mul with leaky_relu activation
---    fused 0 elementwise_mul with swish activation
---    fused 0 elementwise_mul with hardswish activation
---    fused 0 elementwise_mul with sqrt activation
---    fused 0 elementwise_mul with abs activation
---    fused 0 elementwise_mul with clip activation
---    fused 0 elementwise_mul with gelu activation
---    fused 0 elementwise_mul with relu6 activation
---    fused 0 elementwise_mul with sigmoid activation
---    fused 0 elementwise_add with relu activation
---    fused 0 elementwise_add with tanh activation
---    fused 0 elementwise_add with leaky_relu activation
---    fused 0 elementwise_add with swish activation
---    fused 0 elementwise_add with hardswish activation
---    fused 0 elementwise_add with sqrt activation
---    fused 0 elementwise_add with abs activation
---    fused 0 elementwise_add with clip activation
---    fused 0 elementwise_add with gelu activation
---    fused 0 elementwise_add with relu6 activation
---    fused 0 elementwise_add with sigmoid activation
---    fused 0 elementwise_sub with relu activation
---    fused 0 elementwise_sub with tanh activation
---    fused 0 elementwise_sub with leaky_relu activation
---    fused 0 elementwise_sub with swish activation
---    fused 0 elementwise_sub with hardswish activation
---    fused 0 elementwise_sub with sqrt activation
---    fused 0 elementwise_sub with abs activation
---    fused 0 elementwise_sub with clip activation
---    fused 0 elementwise_sub with gelu activation
---    fused 0 elementwise_sub with relu6 activation
---    fused 0 elementwise_sub with sigmoid activation
---    fused 0 elementwise_mul with relu activation
---    fused 0 elementwise_mul with tanh activation
---    fused 0 elementwise_mul with leaky_relu activation
---    fused 0 elementwise_mul with swish activation
---    fused 0 elementwise_mul with hardswish activation
---    fused 0 elementwise_mul with sqrt activation
---    fused 0 elementwise_mul with abs activation
---    fused 0 elementwise_mul with clip activation
---    fused 0 elementwise_mul with gelu activation
---    fused 0 elementwise_mul with relu6 activation
---    fused 0 elementwise_mul with sigmoid activation
OCR socket mode. Addr: any, Port: 8484
OCR init completed.
Socket init completed. 0.0.0.0:8484

然后我使用客户端工具（如：postman等）发送post请求：（对于整个json，我试过使用ascii转义后进行post请求）

服务端出现了：

Client connected. IP address: 192.168.1.150:2499
Failed to receive data.

Client connected. IP address: 192.168.1.150:3026
Failed to receive data.

如何才能在linux上实现一个api接口的服务，让客户端发送请求就可以得到识别的结果呢？

[hiroi-sora]

为什么请求到 /image_ocr 呢，是做了反代吗？

[Gavin1937]

首先，当前的PaddleOCR-json只提供了一个tcp套接字远程服务器，而postman是一个http请求工具（应该是可以当成套接字客户端来用的）、post请求也是一个http的概念。PaddleOCR-json的服务器是无法处理http请求的。你需要用一个tcp套接字客户端来发送json数据，你可以看看你的语言是否支持套接字通信。

然后你遇到的错误发生在这里（报错在220行）：

PaddleOCR-json/cpp/src/task_linux.cpp

Lines 197 to 223 in 2f6cc2c

	// 接收任意长度数据
	std::string strIn; // 接收数据存放处
	char buffer[1024]; // 缓冲区
	int bytesRecv = 0;
	while (true)
	{
	bytesRecv = recv(clientFd, buffer, sizeof(buffer), 0);
	// 没收到数据，可能客户端断开连接或连接错误
	if (bytesRecv <= 0)
	break;
	// 将本次接收到的数据追加到存放处末尾
	strIn.append(buffer, bytesRecv);
	// 到达末尾符，认为数据已全部接收完毕
	if (buffer[bytesRecv - 1] == '\0' || buffer[bytesRecv - 1] == '\n')
	break;
	}
	// 没有接收到数据 | 接收到0字节
	if (bytesRecv <= 0)
	{
	std::cerr << "Failed to receive data." << std::endl;
	close(clientFd);
	continue;
	}

当引擎没从客户端套接字里读出数据时就会报Failed to receive data.，接着引擎会重置套接字连接让客户端重新连一遍（这就是为什么你看到两段Client connected.输出了不同的端口）
有可能是客户端已经写完数据正常关闭套接字了，又或者是连接超时或什么其他报错。你可以尝试在上面这段代码的220-221行之间插入一行输出来检查具体的报错。比如：

std::cerr << bytesRecv << ", " << errno << std::endl;

不过这里确实处理的不好，没有一个明确清晰的报错。可以考虑多加一点报错，或者直接等重构时弃用tcp套接字换成http服务器。

[v587xpt]

为什么请求到 /image_ocr 呢，是做了反代吗？

在v1.3.0版本，还无法在Linux上部署，我们把这个项目部署在了windows上，并用python写了一个api接口，客户端只需要将图片的base64请求到api中即可返回识别的结果，这个python api的url就是 /image_ocr

[Gavin1937]

这确实是个bug，Linux 和 windows 官方都对recv()函数返回0有着明确的定义：

如果套接字连接被客户端正确的关闭（类似于"end-of-file"的情况），那这个函数就会返回0。

而且套接字是分段发送数据的，这就更容易出现“发送0字节”的情况，也很合理。没收到数据不应该被当成一个连接错误来处理。
等我开个pr修一下