Mistaken same-host rendezvous mode may result in misleading error reports

[ethouris]

When you try to make a rendezvous-type connection to another host, while the destination host actually resolves to localhost (or, more simply, when the bound IP address is the same as the target IP address), it causes unexpected things to happen and it causes misleading errors.

That is, the result is that the packet sent to the socket is then received back by the sender as if it had received a packet from the "peer", and it tries to resolve it as a peer's handshake. In case of HSv5 this results in having equal cookies, which causes an immediate error due to unresolved cookie contest, however this happens immediately after running this command, without even starting the command on the "peer side". This "problem resolution" is however rather accidental, and it is desired that the problem be resolved more predictable way.

Normally the rendezvous sockets have to be first bound locally, so I think it should be enough to check in the function called directly from srt_connect that if this a rendezvous socket, then the target IP address must differ to the bound IP address, otherwise this function results in error.

[ethouris]

Further study: this check requires getting all IP addresses of the current machine and check the target address against each of them, if the bound address (s->m_pSelfAddr, with CUDTSocket* s) contains sin_addr.s_addr == INADDR_ANY.

[ethouris]

#377 Submitted to add the check to the srt-test* applications, the check is done before the call to srt_connect.