Blocking connection between server-client using socket communication - c++

Question

I am having some strange problem with my client-server connection using UDP and SFML and I am slowly running out of ideas what might be wrong, so maybe someone will be able to help me.
Currently I can connect client to server and send message from server to client. When I kill the client application and restart it again (on this same machine), provide this same connection parameters of server, nothing happens. It appears like if there is no connection established. Client is just waiting for message form server, while server is constantly sending messages at the same time.
My server side looks like that:
std::shared_ptr<sf::UdpSocket> startUdpServer()
{
std::cout << "Local address: ";
std::cout << sf::IpAddress::getLocalAddress().toString() << std::endl;
std::cout << "Public address: ";
std::cout << sf::IpAddress::getPublicAddress().toString() << std::endl;
std::shared_ptr<sf::UdpSocket> socket(new sf::UdpSocket());
if(socket->bind(sf::Socket::AnyPort) != sf::Socket::Done)
return nullptr;
std::cout << "Server is listening to port " << socket->getLocalPort() << ", waiting for a message... " << std::endl;
return socket;
}
std::pair<sf::IpAddress, unsigned short> runUdpServer(std::shared_ptr<sf::UdpSocket> socket)
{
// Wait for a message
char in[128];
std::size_t received;
sf::IpAddress sender;
unsigned short senderPort;
if (socket->receive(in, sizeof(in), received, sender, senderPort) != sf::Socket::Done)
{
std::cout << "Connection error" << std::endl;
return std::make_pair(sender, senderPort);
}
std::cout << "Message received from client " << sender << ": \"" << in << "\"" << std::endl;
return std::make_pair(sender, senderPort);
}
void sendUdpMessage(std::shared_ptr<sf::UdpSocket> socket, std::pair<sf::IpAddress, unsigned short> config,
std::string message)
{
const char* out = message.c_str();
if (socket->send(out, sizeof(char) * message.length(), config.first, config.second) != sf::Socket::Done)
{
std::cout << "Message not send" << std::endl;
return;
}
}
void sendMessages(std::shared_ptr<sf::UdpSocket> socket, std::pair<sf::IpAddress, unsigned short> config)
{
if(config.first != sf::IpAddress::None)
{
while(true)
sendUdpMessage(socket,config,"Test msg");
}
else
std::cout << "Message sending error" << std::endl;
}
auto socket = startUdpServer();
auto config = runUdpServer(socket);
std::thread messages_thread(sendMessages,socket,config);
and my client:
std::shared_ptr<sf::UdpSocket> startUdpClient()
{
sf::IpAddress server;
do
{
std::cout << "Type the address or name of the server to connect to: ";
std::cin >> server;
}
while (server == sf::IpAddress::None);
unsigned short port;
std::cout << "Type the port number: ";
std::cin >> port;
std::shared_ptr<sf::UdpSocket> socket(new sf::UdpSocket());
sf::Packet packet;
const char out[] = "Hi, I'm a client";
if (socket->send(out, sizeof(out), server, port) != sf::Socket::Done)
return nullptr;
return socket;
}
void runUdpClient(std::shared_ptr<sf::UdpSocket> socket)
{
char in[256];
std::size_t received;
sf::IpAddress sender;
unsigned short senderPort;
if (socket->receive(in, sizeof(in), received, sender, senderPort) != sf::Socket::Done)
return;
std::cout << "Message received: \"" << in << "\"" << std::endl;
}
auto socketUDP = startUdpClient();
std::thread messagesThread(receiveMessages,socketUDP);
void receiveMessages(std::shared_ptr<sf::UdpSocket> socket)
{
while(true)
runUdpClient(socket);
}

Answer 1

With networking there are 2 very important key notes to remember with UDP and TCP.
TCP - is connection based, this means everytime it attempts to send it a message it needs to have someone on the other end.
UDP - is connectionless based, this means he will send information to where ever you want him to. He can send and receive information, but in order to receive data he needs to be binded to a port. So in your server you are binding him to the same port everytime.
In your client you are giving him a port to send information to, not binding him to a specific port. Whenever you shut down your client he should release the port, and whenever you restart the client he should bind to the same port, if you want him to be able to receive data from your server. If you don't essentially whats going on is the data gets to the IP and port it was sent to, but there is no application associated with that port so the packet is lost.

Answer 2

In order to communicate between two parties via UDP, each side needs a unique (address, port) pair. Typically the server binds its socket to a fixed/well-known port, and the client port varies by client -- hence allowing multiple clients to communicate with the same server, each on their own port.
If your client, as here, doesn't explicitly bind its socket to a port, the operating system will dynamically allocate a "random" unused port to it and automatically bind it on the first use of the port for sending data. As long as that client continues to use the same socket, the port number is fixed.
However, when you restart the client side, it gets a new socket and on its first send using the new socket, the OS binds the socket to a new port. Your server however, is assuming that the client port number is still the number that it received from the first client.
Because of the way this works, for UDP servers, the usual pattern is that every message stands alone. The server makes note of the client's address and port number every time it receives a message and then responds back to that address/port. The server typically doesn't assume that any two consecutive messages will come from the same client as there is no way for it to know when any given client has disappeared.
(You can build your own more durable "connection" notion atop UDP -- as NFS traditionally did, for example -- but that is a significant amount of work that requires due care in designing your protocol. And it works within this same fundamental model described above.)
It is also possible for your client to always explicitly bind to a port you select. However, that would limit you to running one instance of the client on any one machine (well, on any one network address really).