A list of API-related issues for bonding

[maxsharabayko]

As reported by @jeandube

SRT Version:

• SRT commit 92abcd6 June 19, 2020)
• Merged PR SRTO_OUTPACEMODE option for Output Pace Control #1383
• Merged back-ported ethouris/srt branch dev-fix-epoll-unsub-ipe commit 3084503 (July 1,2020)

Non-blocking mode using SRT "C" API

Note

Those issues listed further are to be confirmed.

The List of Issues

2. get SRTO_GROUPTYPE in listen_callback on listener socket fails - RESOLVED/FIXED

new socket passed in listen_callback((void* opaque, SRTSOCKET newsock,...) is not yet a group socket.

The group socket is the one returned by srt_accept. So the doc (API.md) telling get(SRTO_GROUPTYPE) can only be
called from inside the listener callback handler is wrong as it assumes srt_accept() is called from the
listen_callback handler. While implementing SRT StreamID I added listen_callback handling but kept the
srt_accept in epoll event, which occurs after listen_callback.

3. new socket in listen_callback and event_callback (accepted) are not the same:

(gdb) p/x lstn->listen_cbq[lstn->listen_cbq_head].sock.u
$2 = 0x1abe8a9e
(gdb) p/x lstn->listen_cbq_head
$3 = 0x0
(gdb) p/x srtc->sock.u
$4 = 0x5abe8a9d

Not sure if this is an issue as I am still trying to make a broadcast group of one(1) socket working.
listen_callback passes the actually connected socket while
srt_accept returns the group socket
According to bonding-into.md only 1st connection is handled this way.
Since subsequent connections details are only available from srt_group_data() what is the utility of passing
connected socket via listen_callback instead of the group socket directly.

4. SRT_SOCKGROUPDATA.peeraddr not set after srt_accept - RESOLVED/FIXED
   srt_group_data(grp) called after grp=srt_accept(...)
   most fields are set in data[0] but not peeraddr
   Workaround uses srt_getpeername(data[0].id,...

(gdb) p/x srtc->rt.group_data
$2 = {{id = 0x1e216fa7, peeraddr = {ss_family = 0x0, __ss_align = 0x0, __ss_padding = {0x0 <repeats 112 times>}}, sockstate = 0x5, memberstate = 0x1,
    result = 0x0}, {id = 0x0, peeraddr = {ss_family = 0x0, __ss_align = 0x0, __ss_padding = {0x0 <repeats 112 times>}}, sockstate = 0x0, memberstate = 0x0,
    result = 0x0}, {id = 0x0, peeraddr = {ss_family = 0x0, __ss_align = 0x0, __ss_padding = {0x0 <repeats 112 times>}}, sockstate = 0x0, memberstate = 0x0,
    result = 0x0}, {id = 0x0, peeraddr = {ss_family = 0x0, __ss_align = 0x0, __ss_padding = {0x0 <repeats 112 times>}}, sockstate = 0x0, memberstate = 0x0,
    result = 0x0}}
(gdb) p/x srtc->rt.group_data[0].peeraddr
$3 = {ss_family = 0x0, __ss_align = 0x0, __ss_padding = {0x0 <repeats 112 times>}}

5. [core][BUG] Group connection errors are reported misleadingly #1415 - impossible to inform the application properly about the reason of connection failure for a member connection

[jeandube]

1)SRTO_MINVERSION was an application bug. Not an SRT lib issue.

[maxsharabayko]

Updated the description. Thanks.

Item removed:

1. set SRTO_MINVERSION on group fails:
   Trying to set SRTO_MINVERSION on a socket created with srt_create_group as recommended in socket-groups.mx
   08:02:33.810665 mxptool: [1]srt: could not set MINVERSION: Operation not supported: Invalid socket ID

[ethouris]

Problems 2 and 3 seems to have been solved, @jeandube please confirm.

Problem 4 is reported through #1420.

[jeandube]

Problem 2 is still there. As reported this is a documentation problem. There is no GROUPTYPE available in listen callback. If application want to reject call based on what the caller asked for and what the server is willing to provide this is the place to check. Also the group type is not set for a listen (only that this is a GROUPCONNECT) caller decides the type. I think the server shall be able to decide to accept or reject each individual connect.
Problem 3 was more a remark in search for improvement. I would say that in general the management of the individual links by the application are not easy. The group socket is used for data transfer while the individual link sockets are needed to manage the links since the application has the responsibility to re-establish lost connections. Individual links epoll events are "stolen" by the lib and link management with msg control will add a toll on poor CPU platforms and probably force serious architecture changes since the connection event detection are not be detected in the thread context of non-group application.

[ethouris]

I tested problem 2 using srt-test-live application. This application has several predefined listener callbacks for testing purposes and there's one for that purpose, activated by -hook groupcheck option and it's available in testing/srt-test-live.cpp source under the SrtCheckGroupHook function name. I ran the listener:

> ./srt-test-live udp://:5556 srt://:5000?groupconnect=1\&blocking=no -v -hook groupcheck

I used the nonblocking mode so that it's closer to your case (I detected a small bug in the app btw., which made the hook unavailable in the non-blocking mode).

When I contact from a group caller, the result is:

Binding a server on :5000 ...
 listen... [ASYNC] (conn=1)
listener: @296933981 - accepting GROUP type=backup connection    <<------- (HERE is the groupcheck hook printing)
[EPOLL: 1 sockets]  accept... connected(group epoll 4).
Setting SND blocking mode: false timeout=0

When I contact from a single-socket connection:

Binding a server on :5000 ...
 listen... [ASYNC] (conn=1)
listener: @46789124 - accepting SINGLE connection    <<------- (HERE is the groupcheck hook printing)
[EPOLL: 1 sockets]  accept... connected [10.129.10.66:5000] <-- 10.129.10.96:39814
Setting SND blocking mode: false timeout=0

[jeandube]

I updated to 4aa6fbb and poblem #4 (SRT_SOCKGROUPDATA.peeraddr not set) is fixed.

[jeandube]

Issue #2 fixed with 4aa6fbb and an application bug fixed, which may have been the problem since then (log not printing right var).

[ethouris]

As for Issue 3, it's more about a complaint for the current API and hard time for the application to keep control over the links, especially in non-blocking mode. This problem is to be solved by #1464.

[maxsharabayko]

Issues 1, 2, 4 are resolved/fixed.
Issue 3 -> #1464
Issue 5 -> #1415