Closed dumblob closed 9 years ago
Its state will be $bound
, albeit that is irrelevant for the current TcpListener
implementation.
Ok, if the state is $bound
, then there is no issue. But why would it be irrelevant for the current implementation?
Because bound&listen always come in pair in order to avoid unnecessary intermediate states.
Sure, that's how I understood it and I welcome this solution. But in this case I'm pretty sure, that after catching the exception, the socket is in bound state, but this information is not visible/available and thus e.g. calling DaoNetLib_Listen()
again will call bind()
again which might cause issues.
calling DaoNetLib_Listen() again will call bind() again which might cause issues.
It will close the socket first.
Oh, now I see - DaoSocket_Delete()
does it.
It seems, that if the socket was properly bound, but
listen()
failed, the socket will remain bound until it's shutdown/closed. This might be inconvenient for other processes/threads as the programmer will see a socket, but the raised error would be aboutlisten()
and the information, that the socket is actually properly bound is not accessible.