Client fails to bind in separate thread

[The Inzuki]

Oops, totally forgot that the access violation doesn't happen anymore. The problem now is that the client's console is spammed with "Failed to receive data : the UDP socket first needs to be bound to a port".

[Laurent]

Ok. But please can you remove all this useless stuff?? We just need a simple Send/Receive to test the bug, if Receive fails we don't need the whole block that follows the call (since it's not executed, and not relevant to the problem anyway). And I don't think we need a window...

[GatorQue]

I think I might have an explanation of what is wrong.  It appears that the client is trying to receive on a port that it hasn't bound.  Notice how the code below is trying to receive on port 1357, but earlier it was bound to port 0 (which amounts to an ephemeral, or random, port assigned by the OS).

Client:

Code: [Select]


...
if(!Client.Bind(0))
return 1;
...
Client.Send(Name, Server, 1357);
...
if(Client.Receive(Ser, Server, 1357) == sf::Socket::Done){
...
Client.Close();


Normally, when creating a network application your server has a fixed port and the client uses an ephemeral port like you have already shown above.  When the client wants to send data to the server is does so to the fixed port provided above.  But when the client wants to receive data from the server it must do so on the ephemeral port assigned by the OS.  I'm not sure how SFML handles returning ephemeral ports, there is probably some Client.GetPort() call that can be made to determine the ephemeral port assigned.  If that is the case, you should be able to do a Client.Receive using this port and prevent a socket not bound error.  Also, you must be careful to keep track of each clients ephemeral port as they connect on the server side of your code.  The connection packet received can be used to obtain the ephemeral port being used by the client so that all future server messages sent from the server to the clients will use the correct ephemeral port.

Hopefully this information was useful (and accurate), please let us know how it works out.

[Laurent]

I think you spotted the error but it's not what you thought.

This line:

Code: [Select]

Client.Receive(Ser, Server, 1357)
... doesn't mean that the client tries to receive on port 1357; UDP sockets always receive on the port they are bound to.

In fact this line shouldn't compile, the third argument of SocketUDP::Receive is a reference to an integer to fill with the remote port where the message came from. So there's no way it can compile with a literal integer as the third argument.

[GatorQue]

Thanks again for the clarification, I knew my answer was probably not quite right, I didn't have time to check the docs, perhaps the code that was pasted was slightly modified but not compiled before being posted.