Defining address family at SRT socket creation time

[maxsharabayko]

Some background

The discussion is extracted from #691.
With the release of SRT version 1.4.2 the API srt_socket(int af, int type, int protocol) became deprecated in favor of the newer API srt_create_socket(). The latter one does not let specifying the address family such as AF_INET or AF_INET6.
The old API function was similar to the Linux socket creation interface, thus SRT API looked more familiar to new users.

int socket(int socket_family, int socket_type, int protocol);

The type and protocol arguments always had only one expected value. The af parameter became unused in 1.4.2 with a change in socket family handling.

Current API

To create an IPv6 SRT socket using srt_create_socket() you would need to bind it either to a specific IPv6 address or to IPv6 any (e.g. IN6ADDR_ANY_INIT).

There is also a useful socket option SRTO_IPV6ONLY.

Why would you specify address family at socket creation

Possible advantages of specifying socket family in srt_socket(..):

const int sock = srt_socket(AF_INTE4, .., ..);
srt_bind(sock, <some IPv6 address>); // Return ERROR
srt_connect(sock, <some IPv6 address>); // Return ERROR

const int sock = srt_socket(AF_INTE6, .., ..);
srt_bind(sock, <some IPv4 address>); // Return ERROR
srt_connect(sock, <some IPv4 address>); // OK - IPv4 over IPv6

Not sure though if it covers any use cases of SRT integrators.

[ethouris]

Let me describe the general situation concerning sockets.

First thing is to create a socket. Then, depending on purpose, various things would be made with it. Currently in SRT we have caller, listener and rendezvous.

1. Caller: After creation you will be doing srt_connect with specified address. Optionally you can do srt_bind prior to connecting.
2. Listener: First srt_bind is obligatory, then srt_listen.
3. Rendezvous: It is obligatory to do srt_bind and then srt_connect.

Result: no matter the mode, in most cases the creation will be followed by srt_bind, or - in caller mode - at least srt_connect, in both cases specification of the address in particular domain is necessary. Both these functions require specification of the address using the sockaddr based structure with appropriate value of AF_INET or AF_INET6 set to the sockaddr::sa_family field.

In result, there's absolutely no purpose in specifying the "family" when creating a socket. The only thing that a "fixed" family will do on a socket is that it will increase opportunities for runtime errors.

The reason why the BSD socket API requires specification of the family during socket creation could be:

• Limitations of the implementation (early implementation of the BSD socket API done in 1983 year could not be done as "family independent"). That's not the case in SRT, especially that it only allows AF_INET and AF_INET6 families.
• Ability to reuse or repurpose a socket. Indeed, when repurposing a socket that was once set particular family, it is no longer possible to alter the family on such a socket. However, this repurposing isn't implemented in SRT anyway - you can always bind a socket only ONCE, and if you want to have a socket bound to any other address, you have to close the used one and create a new one. Also a connected and broken socket can only be purged of remaining data and closed.

There aren't any known scenarios where having a fixed family on a newly created socket would be of any benefit for the application.

[MorelloCherry]

@maxsharabayko Thank you for raising this again.

You were raising the point about the use case? Well, in our product we have a clear separation between IPv4 and IPv6. Creating a socket for this mode did not create an overhead as we favour the BSD socket APIs. Now for SRT once we advance our SRT release beyond V1.4.1 we need to create a specific solution and that is the unfavourable option.

@ethouris Perhaps before making changes like this it would be much appreciated to check if anybody actually needs that API and come forward with a god reason. I agree that most parameters were ignored but keeping in line with the BSD socket API was good and we used it. Now since the API has been removed I have got 2 options:

1. Rework our SRT supporting application to support the newer API
2. Make a local patch that brings back the lost API and therefore limits the change to SRT only rather than reworking our app.

Somewhat I lean to option 2 though...

Thank you for reading this.

Kind regards,
Oliver

[maxsharabayko]

@oliverschoen
Do I understand correctly, that you were using the "old" srt_socket(..) API this way:

const int sock = srt_socket(AF_INTE4, .., ..);
srt_bind(sock, <some IPv6 address>); // Return ERROR
srt_connect(sock, <some IPv6 address>); // Return ERROR

Are there other examples of the benefit of the family argument?
Just to better understand possible workflows where the old API provides a benefit.

[ethouris]

@ethouris Perhaps before making changes like this it would be much appreciated to check if anybody actually needs that API and come forward with a god reason. I agree that most parameters were ignored but keeping in line with the BSD socket API was good and we used it.

I can see two possibilities why this could be a problem, please correct me if I'm wrong:

A. The old API could not be used anymore
B. The updated old API no longer reports errors it was supposed to

Now since the API has been removed I have got 2 options:

1. Rework our SRT supporting application to support the newer API
2. Make a local patch that brings back the lost API and therefore limits the change to SRT only rather than reworking our app.

If it's the A case above - you probably should do it in the future, but there's no hurry. The srt_socket function will stay here for a longer time and it still works the same way, also together with the rest of the API, at least if you regard correct usage.

If this is the B case - I'm sorry that it happened, but my understanding on reporting errors from the API is such that it only informs your application that library API cannot perform the operation (and this usage should be also mentioned in the documentation as wrong). In future however, some new usage cases could be accepted, making previous wrong usage correct now, and it's not considered breaking the backward compatibility.

Kind regards,
MM