TCP/UDP receive error in serial_lte_modem

[Siyou]

Hi,

In our application, we need the TCP/UDP socket keeps alive even when its receiving is timeout. so we changed the process code in do_tcp_receive() and do_udp_recvfrom() to below:

	if (ret < 0) {
		LOG_WRN("recv() error: %d", -errno);
		//do_socket_close(-errno);
		ret = -errno;
	} else if (ret == 0) {
		/**
		 * When a stream socket peer has performed an orderly shutdown,
		 * the return value will be 0 (the traditional "end-of-file")
		 * The value 0 may also be returned if the requested number of
		 * bytes to receive from a stream socket was 0
		 * In both cases, treat as normal shutdown by remote
		 */
		LOG_WRN("recv() return 0");
		//do_socket_close(0);
	} else {
	

After receive timeout(Log output: recv() error: -60), we found the next receive or send will be not available.

In this situation, how to continue to receive and send without closing and recreating the socket?

[Håkon Alseth]

Hi,

 

If you are receiving 0 bytes, it means that the remote side is trying to gracefully shut down the connection, as also discussed here:

https://stackoverflow.com/questions/38021659/can-a-c-socket-recv-0-bytes-without-the-client-shutting-the-connection

Is there a specific reason why you want to keep the socket alive after this point? The connection would be lost at this point and you would need to re-establish a new connection.

 

Kind regards,

Håkon

[Siyou]

Hi Håkon,

Let me separate it to below two questions:
1, For TCP case, we understood the design when the recv() returned 0, but we could not understand it when recv() was timeout(return was -60), we think the socket should keep as open after client recv() from the server which did not send out any data;
2, For UDP case, due to it is not connection based, client is no need to re-establish connection when recvfrom() was timeout, so we think the socket should be kept as open. But we found the UDP recvfrom()/sendto() were not available after the recvfrom() timeout(return also was -60).

PS: the timeout was produced by below steps:
1), Create TCP or UDP socket and bind to TCP or UDP server;
2), invoke recv() or recvfrom() with timeout;
3), before and within the timeout, the TCP or UDP server does not send out any data to client.

[Håkon Alseth]

Hi,

 

Siyou said:

1, For TCP case, we understood the design when the recv() returned 0, but we could not understand it when recv() was timeout(return was -60), we think the socket should keep as open after client recv() from the server which did not send out any data;

Siyou said:

2, For UDP case, due to it is not connection based, client is no need to re-establish connection when recvfrom() was timeout, so we think the socket should be kept as open. But we found the UDP recvfrom()/sendto() were not available after the recvfrom() timeout(return also was -60).

Thank you for clarifying both scenarios, and my apologies for misunderstanding.

This looks like a bug from our side. A timeout doesn't necessarily mean that the connection is gone, it should rather return with the error without closing the socket. The same needs to be handled for errno EAGAIN. I'll report this back to the developers.

 Kind regards,

Håkon

[Siyou]

Hi  Håkon,

Thanks for you info, understand and wait for your update.

[Håkon Alseth]

Hi,

 

Proposed fixes are in this pull-request:

https://github.com/NordicPlayground/fw-nrfconnect-nrf/pull/1971

 

Kind regards,

Håkon