[FR] Get socket's NIC ID via API

[maxsharabayko]

Add a possibility to determine the network Interface ID being used for an SRT connection. Of a particular interest are SRT sockets accepted from a listener bound to INADDR_ANY and accepting connections on any network interface. Once an SRT connection is accepted, the system usually uses a preferable network interface for it. Applications may benefit from knowing which interface has been assigned. Even though the interface may happen to change in runtime, the update must be available to the application.

Maybe the best solution would be to reuse the SRTO_BINDTODEVICE socket option to get the NIC's name for an accepted socket.

For a group member connection the token field (currently used only for caller) of the SRT_SOCKGROUPDATA structure could be reused for accepted member connections. This would likely add a confusion though, and would not cover regular single-socket connections.

The srt_getsockname API function can be used for retrieving a sockaddr. Still it does not tell directly the interface being used.

The fallback solution is adding a new API function srt_getsocknic or alike providing an ability to retrieve the network interface index and name.

[MahendharN]

@maxsharabayko I have taken up the issue and have started working on it.

Will be adding a new API called srt_getsocknic that will provide the nic name.

To get the network interface will add a new function in channels that will getNicname as follows:

• Get network interfaces in the system using getifaddrs.
• Check if IP address in m_BindAddr.sin.sin_addr matches with IP address in one of the interfaces.

The function getNicname (of channel) will be called everytime bind() api is called. And will be stored in a new internal attribute of CUDTSocket (say m_InterfaceName)

Every time srt_getsocknic is called , the value will be fetched from CUDTSocket (from m_InterfaceName) and will be provided.

[ethouris]

Just FYI, I started something of that kind, with restoring some old proposal to prevent "connecting to self", for which there's used the function that reads the list of local interfaces and their address: #2989.

You can use some parts of it as a reference, among others, note that the implementation of the local interface reading is system-dependent and on Windows it's kinda nontrivial. You have this code working and ready in this PR, together with all required changes in the build definition.

The purpose of this PR was more-less the same that you are doing, but I haven't actually provided there what was required by this ticket, so I have put this aside. Feel free to take any part of this as you need.

[MahendharN]

Will look into it. Thank you @ethouris

[MahendharN]

@maxsharabayko Is there any test focus that has to be kept in mind on the changes that will be done ?

[maxsharabayko]

@MahendharN Probably just some system with a couple of network interfaces would be needed. Both could reach the same remote IP in one test setup, and have different subnets in another test setup. Then just test some corner cases, e.g. what to do if one interface goes down, and so on.