SRT socket addr with inaccurate socket type.

[suzp1984]

srs/trunk/src/protocol/srs_protocol_srt.cpp

Line 197 in fa8096a

hints.ai_socktype = SOCK_STREAM;

SRT use UDP socket, so the socket type should be SOCK_STREAM, this api is used to get the addrinfo with TCP type. It's not accurate, at least no perfect.
The usual steps to create a socket (TCP/UDP) is: socket(domain, type, protocol) -> bind(socket, const struct sockaddr*, address_len); I found create a UDP socket and bind with a TCP struct sockaddr is ok. It seem the system api is tolerant with this mistake, I also no idea whether it's a mistake or not. But I guess gives the socket a more accurate addr would be better.

Here is the code to verify bind socket with a struct sockaddr with different type.

#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <netdb.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main() {

    struct addrinfo hints;
    memset(&hints, 0, sizeof(hints));
    hints.ai_family   = AF_UNSPEC;
    hints.ai_socktype = SOCK_STREAM;
    hints.ai_flags    = AI_NUMERICHOST;

    struct addrinfo* r = NULL;

    if(getaddrinfo("0.0.0.0", "10080", (const struct addrinfo*)&hints, &r)) {
        printf("getaddrinfo hints=(%d,%d,%d) failed\n", hints.ai_family, hints.ai_socktype, hints.ai_flags);
        return -1;
    }

    printf("getaddrinfo r=(%d,%d,%d) success\n", r->ai_family, r->ai_socktype, r->ai_flags);


    int s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);

    if (bind(s, r->ai_addr, r->ai_addrlen)) {
        printf("bind socket failed\n");
        return -2;
    }


    getchar();
    
    close(s);
    
    free(r);
    r = NULL;

    return 0;
}

[winlinvip]

I'm unsure about the correct parameter to use with the getaddrinfo function, which is utilized to obtain an address for binding a socket. Please conduct further research and study on this issue. If you confirm that this issue needs correction, please submit a pull request.

I appreciate your effort in researching and providing examples concerning this issue. However, it seems that more work is needed to fully understand the problem. I recommend reading and studying further, and doing more work to clarify this issue, until you can determine whether it is a bug.