Open maxsharabayko opened 1 year ago
Are you sure that it is possible to obtain this number in case when this is the first connection in the group?
What I really need is to distinguish a new group connection from a new link of an already connected group.
Well, the handshake structure is passed to the runAcceptHook method, and this is also used to extract the group type that can be later obtained. Of course, there's only the PEER's group ID available this way, but there can be also called a function to find the group that has that peer ID, and that group ID can be made available through the srt_groupof
call, similarly like this is done for the group type. Of course, for the very first call in the group it would return an invalid ID, but I think that's not a problem.
(Elaborating on @ethouris's comment)
As a hack, a group connection may be distinguished from a regular connection attempt via the SRTO_GROUPTYPE
option. A regular connection will have the value 0, while a group member connection will have a non-zero group type value.
Regarding the group ID. At the point of the listener callback, we only know the group ID of a peer, but not the local one unless a local group already exists. There is a corner case though when both members connect over separate listener ports in parallel. Then there would be two listener callback calls both BEFORE a local group is created, meaning both would be treated as a new group connection request.
SRT.cn: @600335716: runAcceptHook: peer group ID @1332354199 (does not exist).
SRT.cn: @600335715: runAcceptHook: peer group ID @1332354199 (does not exist).
SRT.gm: addGroup: @1674077536 <--- Local group has been created!!!
Example 2: one member connects a bit later.
SRT.cn: @803205604: runAcceptHook: remote group ID 1904656706 (does not exist).
SRT.gm: addGroup: @1876947425 <--- Local group has been created!!!
SRT.cn: @803205603: runAcceptHook: remote group ID 1904656706 (exists) <--- Second member connects
The group type does not distinguish an added link from a new group. The peer group ID is a good solution and probably better than the local one due to the listen_callback race condition. It tells that only one group will be created. It help count both group links and accepted connections.
Could be added using the #ifdef SRT_160_API_PREVIEW
in the next release, and replace the previous callback in v1.6.0.
Drawbacks:
srt_groupod(SRTSOCKET)
operational from the listen callback.I think there's not much we can do about that corner case when connections to the same group are being added perfectly simultaneously. Although I think that the probability of the number of simultaneous connections reporting simultaneously decreases with the number of connections.
Note that you can request yourself to be notified with the new member connection and you can simply forcefully break the connection if it exceeds the limit.
BTW Changes in the callback function signature is a bad idea. It introduces hard backward ABI incompatibility.
Problem Statement
The SRT listener callback currently (SRT v1.5.2) does not provide a way to find out SRT group ID of a socket to be accepted.
Solution 1 (Prefered)
Extend the listener callback with the Group ID value, or better with some key-value array to enable further extensions in the future.
The Group ID value can be used to limit the number of group connections on a listener socket.
Solution 2 (Discouraged)
Calling
srt_groupof(ns)
returnsSRT_INVALID_SOCK
because the HS was not yet parsed, and no group has been created/assigned to a socket. Creating a fake group ID value for the socket ID to be accepted may be a way around it, but would add unnecessary and potentially confusing logic.