Boost and Windows sockets - Properly handling TCP client disconnect scenarios - c++

Question

I have a class called ServerConnectionHandler that creates a boost thread for reading data from the server. The boost thread is bound to the ServerConnectionHandler object. Relevant pieces of code are below:
ServerConnectionHandler::~ServerConnectionHandler()
{
close();
}
void ServerConnectionHandler::close()
{
closesocket(m_ConnectSocket);
WSACleanup();
}
void ServerConnectionHandler::MsgLoop()
{
int size_recv = 0;
char chunk[DEFAULT_BUFLEN];
while(1)
{
memset(chunk, 0, DEFAULT_BUFLEN);
size_recv = recv(m_ConnectSocket, chunk, DEFAULT_BUFLEN, 0);
if(size_recv > 0)
{
for( int i=0; i < size_recv; ++i )
{
if(chunk[i] == '\n')
{
m_tcpEventHandler.OnClientMessage(m_RecBuffer);
m_RecBuffer.clear();
}
else
{
m_RecBuffer.append(1, chunk[i]);
}
}
}
else if(size_recv == 0)
{
close();
const std::string error = "MsgReceiver Received 0 bytes because connection was closed. MsgReceiver shutting down.\n";
m_tcpEventHandler.OnClientSocketError(error);
break;
}
else
{
char error [512];
sprintf(error, "Error on Receiving Socket. Recv=[%d], WSAError=[%d]. MsgReceiver shutting down.\n", size_recv, WSAGetLastError());
m_tcpEventHandler.OnClientSocketError(error);
close();
break;
}
}
// NOTE: This will eventually call the destructor of ServerConnectionHandler...
m_tcpEventHandler.OnClientDisconnect("Disconnected. Reason: Remote host snapped connection.");
}
My problem is that when close() is called in the destructor, the receiver thread is still running and crashes when it attempts to call any of the m_tcpEventHandler.OnClient...() methods because the object has been destroyed at this point.
I need to be able to handle this cleanly in 3 different cases:
When the user manually disconnects the client (the destructor will be called in this case).
When the client is disconnected from the server (maybe because the server crashed for example).
When the application shuts down (needs to cleanly disconnect everything - similar to #1).
Right now, this code only works for case #2. I don't want to slow down the receiver thread with any locking as the performance is critical. From what I've read, I've seen people create a volatile bool flag that tells the receiver thread to stop. The problem I see with this approach is that what if it is in the middle of handling a message (m_tcpEventHandler.OnClientMessage()) right when the destructor is called? Then it could immediately hit code for the destroyed object (m_tcpEventHandler could in turn use ServerConnectionHandler's member variables or methods). I can't think of a clean way to handle all 3 cases here.

Answer 1

Before you close the socket in the destructor, shut it down for input. That will cause the receive thread to get an end of stream and exit nicely. You might want to add a little handshake between the dtor and the receiver thread before the final close, or you might just want to rely on the receiver thread closing the socket and not close it in the dtor at all.

Answer 2

"My problem is that when close() is called in the destructor, the receiver thread is still running" - seems to me your problem is merely thread synchronization, then. Little to do with connections.
Making the communications asynchronous gives you a lot more control over the receiving thread.
You could e.g. use Boost Asio to do the asynchronous socket reads (and writes, of course). If you add an "infinite" deadline_timer to the asynch queue, you can just cancel() that timer, which could be used by the receiving thread to stop the receive and do some more cleanups (e.g. write a "Goodbye" message to the remote end).
(If the latter were not required, just cancelling all async operations could be achieved by simply shutting down the io_service. That would be rather uncourteous, but not a bad idea in fast shutdown paths.)