[FR] A callback for rejected connection attempts on a listener.

[jeandube]

I am trying to report in the U/I the connection failure reason to help diagnose settings problems. I am not calling srt_connect_callback() for a listener as I assume it was the caller counterpart of srt_listen_callback for listener but I realize I may be wrong. I am interested in getting listener connection rejection done in the background of in libsrt (before calling srt_listen_callback_fn()).

[ethouris]

There has never been intended any mechanism to inform the listener application that there was some kind of attempt to connect and it has been rejected. Frankly, I never thought it may be needed. Granted, there doesn't exist any good model for it in other projects - TCP, for example, never rejects a connection, at worst it can timeout or be "refused" on the host by not having a bound port.

And no, of course, the "connect callback" also wasn't intended to work with a listener - but OTOH I can't see why not. I would have to dig up how it can be brought to working with a listener socket, but at least I can't see any conflicting situation for it. @maxsharabayko ?

[maxsharabayko]

What if srt_listen_callback_fn is just reused with ns = SRT_INVALID_SOCK if a connection attempt is rejected by SRT?
Not sure if it is good for performance though...

typedef int srt_listen_callback_fn(void* opaque, SRTSOCKET ns, int hs_version
             const struct sockaddr* peeraddr, const char* streamid);

[ethouris]

In the listener callback you don't have access to the internal mechanisms that would cause the call rejection. For example, you can set up a passphrase inside the call, then give up to the library, which will match the password and possibly reject the call. We need something that will be called AFTER the rejection has happened. Might even be the case that you have both listener and caller callback installed on the listener, you set the password on the listener, and in the caller callback you get the notification about the failed passphrase check, AFTER the check has failed. Currently there's no way to do these two things in one callback because they are called at different times.