failure on read

[ig0rb]

Hi, sometimes I have a failure on read, and channel hangup, I think because not all data is ready to be be read (fragmented packet), i implemented a retry with an usleep and it resolved my issue.

it's just a debug: *CLI> [Jan 3 01:09:59] ERROR[127536][C-00000001]: res_audiosocket.c:294 ast_audiosocket_receive_frame: Failed to read data from AudioSocket [Jan 3 01:09:59] ERROR[127536][C-00000001]: res_audiosocket.c:295 ast_audiosocket_receive_frame: XXX 482 960 -1 3 [Jan 3 01:11:59] ERROR[127536][C-00000001]: res_audiosocket.c:294 ast_audiosocket_receive_frame: Failed to read data from AudioSocket [Jan 3 01:11:59] ERROR[127536][C-00000001]: res_audiosocket.c:295 ast_audiosocket_receive_frame: XXX 482 960 -1 3 [Jan 3 01:12:43] ERROR[127536][C-00000001]: res_audiosocket.c:294 ast_audiosocket_receive_frame: Failed to read data from AudioSocket [Jan 3 01:12:43] ERROR[127536][C-00000001]: res_audiosocket.c:295 ast_audiosocket_receive_frame: XXX 482 960 -1 3

[Ulexus]

@ig0rb I'm hesitant to add up to 15ms of delay inside the process loop for this. I'm intentionally using a non-blocking socket for this. I'm more interested in the fixing the problem itself. Can you describe the situation in a bit more detail which is resulting in data from the socket not being available at this time?

[ig0rb]

Hi, sorry for my delay in the answer. When you read from a tcp stream, there is some possibility that sender splitted the original write in 2 packet, this happen because TCP have method to manage congestions. If the writer, force 'nodelay' on the socket probably you will recevice the 'packet' not splitted.

TCP is a stream, and it's better, in my opinion, implement a 'wire reader' that wait the complete frame.

I choosed 15ms, because usally ptime of a voice call is 20ms, it's good to have a not blocking read, but, if sender declare X bytes it's better to wait before drop the connection.

[Ulexus]

Ah, I see what you're saying. Yes, that makes sense. Thanks