Project

General

Profile

Bug #4598

SAT>IP: RTP-over-TCP reset the tuner when data is discarded

Added by Mono Polimorph over 7 years ago. Updated about 6 years ago.

Status:
New
Priority:
Normal
Assignee:
Jaroslav Kysela
Category:
SAT>IP
Target version:
-
Start date:
2017-09-15
Due date:
% Done:

0%

Estimated time:
Found in version:
last commit
Affected Versions:

Description

Hi,

With the current (and working) support for RTP-over-TCP still exists a problem. When the TCP socket is saturated and the write function fails, the data is discarded.. and this is correct. However, sometimes the connection will be closed by the client.

See this part of the log:

2017-09-15 16:19:03.239 satip: SAT>IP DVB-S Tuner #1 (192.168.1.22) - RTSP error -90 (Message too long) [5-0]
2017-09-15 16:19:03.721 subscription: 0009: service instance is bad, reason: Tuning failed

This is the log in the CLIENT side. The server is discarding data, but the client think that the "message" is too long.
I think that the correct behaviour in this case should be:

- If the write fails with TS data (188*N bytes) then discard data in chunks of aligned 188 bytes (no more, no less).
- If the write fails with RTCP data (small chunks of bytes), then retry the write one time or discard the complete message.
- If the write fails with RTSP data (high priority data), then retry the write.
- And only if the same write fails for some time, then close the socket.

The current code that discards the data is in the function http_extra_send_prealloc()@http.c:
http://github.com/tvheadend/tvheadend/blob/3391e1d99d2d9832fa165f01cdd5b0c44444319e/src/http.c#L901

You agree that this is a good strategy?
Regards.

History

#1

Updated by Mono Polimorph over 7 years ago

Hi,

I'm thinking on this: add one parameter to the function "http_extra_send_prealloc()" that indicates if the data can be discarded or not. Then, if the caller is a HTTP response, a RTSP command, or a RTCP message, then set the flag to "no-discard". But if the data is TS, then set it to "discard".

What you think?

#2

Updated by Jaroslav Kysela over 7 years ago

I added may_discard flag to http_extra_send_prealloc(). v4.3-478-gf95cf7d15

But generally, you're a bit wrong. The 'RTSP error -90 (Message too long)' message basically means that the RTSP stream is not consistent (there's very probably a bug somewhere in the data embedding). The current code (server) discards always whole RTP embedded data message, so the server replies should be consistent, but I guess, there might be a bug when the standard RTSP answers are written to the socket. There are two functions which should prevent to write any embedded data when the RTSP answer is being sent - http_send_begin() and http_send_end().

I think that you can do an analysis of the received data, if you see some wrong RTSP / embedded RTP data responses (wireshark etc.) and we can probably use this input to fix the problem on the server side.

#3

Updated by Mono Polimorph over 7 years ago

Jaroslav Kysela wrote:

I added may_discard flag to http_extra_send_prealloc(). v4.3-478-gf95cf7d15

But generally, you're a bit wrong. The 'RTSP error -90 (Message too long)' message basically means that the RTSP stream is not consistent (there's very probably a bug somewhere in the data embedding). The current code (server) discards always whole RTP embedded data message, so the server replies should be consistent, but I guess, there might be a bug when the standard RTSP answers are written to the socket. There are two functions which should prevent to write any embedded data when the RTSP answer is being sent - http_send_begin() and http_send_end().

I think that you can do an analysis of the received data, if you see some wrong RTSP / embedded RTP data responses (wireshark etc.) and we can probably use this input to fix the problem on the server side.

Hi,

Great improvement! Now, using a RTP paylod of 1316 the transport over TCP is robust. No more crashes!

However, still the same trouble with "message too long". See the current log:

2017-09-18 12:23:48.820 satip: SAT>IP DVB-S Tuner #1 (192.168.1.22) - RTSP error -90 (Message too long) [9874-0]
2017-09-18 12:23:49.863 subscription: 0005: service instance is bad, reason: Tuning failed
...
2017-09-18 12:27:20.270 satip: SAT>IP DVB-S Tuner #1 (192.168.1.22) - RTSP error -90 (Message too long) [9874-0]
2017-09-18 12:27:21.172 subscription: 0006: service instance is bad, reason: Tuning failed

Two consecutive executions of different error. Both say "9874-0", and 9874/1316=7.5030...

Please, can you instruct me where to search for the error? With TCPDUMP?
Are you sure that the discard function is discarding complete TS packets?

#4

Updated by Jaroslav Kysela over 7 years ago

Use wireshark, grab the whole RTSP TCP stream between client and server and try to look, if the embedded TCP data are consistent inside ("Follow TCP stream" analyzer in wireshark).

#5

Updated by Jaroslav Kysela over 7 years ago

Or better, attach the output pcap file from wireshark to this bug.

#6

Updated by The Troll about 6 years ago

Hi,

I am also experiencing the issue.
Any news on this subject ?

Thanks

Also available in: Atom PDF