Using shared_ptr is absolutely cheating. I do not think it is real world at all to maintain a connection's lifetime through the use of outstanding receive calls. A simple scenario as to why it is cheating is: What if the server wants to send "Hello" to all clients every 5 minutes? You need a collection. If you have a collection, then you maintain a reference count when using shared_ptrs, and just killed the tutorials lifetime management scheme. In the end, you need to know when it is safe to remove the connection from a collection and destroy it. If I post disconnect, then I am guaranteed no other outstanding IO operation is in progress for that connection. That's a step in the right direction. Only if I have one and only one thread that called io_service.run, but then I still have to know, "when is it safe to destroy my connection object?" Let's say I posted a callback to tcp_server::Disconnect(tcp_connection * connection) from tcp_connection::OnReceive. Is it safe for me then to delete tcp_connection in the body and therefore the socket as well? Will no "cancel" notifications be called back afterward when tcp_server::Disconnect then calls close() on the socket? Or should I call close() back in OnReceive and post a callback to tcp_server::OnDisconnect, which simply deletes the connection object? I think the latter might make sense. I will make an attempt at this in code. Meanwhile a little more clarification on the order of events there might help. Thanks! -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-design-proper-release-of-a-boost-a... Sent from the Boost - Users mailing list archive at Nabble.com.