[BUG] PRE restriction is not applied on a listener socket

[maxsharabayko]

After PR #1776 socket options with PRE restriction can be applied on a listener socket even after srt_listen was called.
E.g. SRTO_LATENCY, SRTO_TSBPDMODE etc. can be changed while listening for incoming connections. As well as other socket options with PRE binding (see APISocketOptions.md).

Example test case fails with the current master and succeeds with SRT v1.4.2.

// Check that setting SRTO_LATENCY after a socket is in the listening state is not allowed.
TEST_F(TestSocketOptions, LatencyPRERestriction)
{
    const int latency_ms = 200;
    int optlen = (int)(sizeof latency_ms);

    StartListener(); // calls srt_bind and srt_listen
    EXPECT_EQ(srt_setsockopt(m_listen_sock, 0, SRTO_LATENCY, &latency_ms, sizeof latency_ms), SRT_ERROR);
}

SRT v1.4.2 does not allow to set an option with PRE restriction if a socket has m_bOpened set to true. E.g. SRTO_LATENCY, SRTO_TSBPDMODE, SRTO_RCVBUF, etc.

The latest master checks only if m_bConnected or m_bConnecting is set to true. Neither m_bOpened, nor m_bListening is checked.

Affected SRT versions

• SRT Version: v1.4.3-rc0

[ethouris]

The #1776 PR changed completely nothing in the general restriction rules since UDT codebase.

The change you observe is because many options have been found with "wrong" restrictions and this has been fixed - among others, SRTO_LATENCY changed the restriction from PREBIND to PRE. This change was completely intended and it was accepted, including changes in the documentation.

[maxsharabayko]

SRTO_LATENCY changed the restriction from PREBIND to PRE. This change was completely intended and it was accepted, including changes in the documentation.

Hm, so you are saying that it is ok to change a value of SRTO_LATENCY, SRTO_TSBPDMODE on a listener socket while listening for incoming connections? And that this change was intended.

[ethouris]

It was intended and accepted. There was no reason to restrict it on the data socket before binding because it didn't influence the binding process.

For a listener socket it changes only one thing: if you can change it on the listener, then you can allow all connections that happen before that change to use the old value, and after - the new value, and you cannot exactly control that process on the connections. For an application this might be seen as a bad practice (it should rather close the socket first, to prevent the new connection during the change time, maybe do something about existing connections spawned off this listener, and then start the listener again, this time with a new value), but there's nothing dangerous that can happen here.