
Hello, i'm using boost 1.34 with the asio c++ library extension for socket communication. At the moment i have following problem. - i open a client class with usage of io service and a connection manager according to the examples TcpClient* client = new TcpClient(ioServiceClient, string(regServer->host), Utilities::intToString(regServer->port), connectionManager, *this); - after connected to a server i send some messages via asio::async_write(socket_, buffer, boost::bind(&TcpConnection::handle_write, shared_from_this(), asio::placeholders::error)); - the connection itself listen to incoming messages via asio::async_read(socket_, asio::buffer(inbound_header_), boost::bind(&TcpConnection::handle_read_header, shared_from_this(), asio::placeholders::error)); So what i have to do is - open connection - send some messages - disconnect The disconnect is done ioServiceClient.post(boost::bind(&ConnectionManager::stop_all, &connectionManager)); So what is my problem: I need to close the connection after sending the last message. At a certain message length the disconnect happens before the message was send completely. That's why i thought putting the disconnect via post to the io service will handle this. But this is not the case. How can i make a clean disconnect when all outstanding messages were send completely?? Thanks for your answers. Bye Bert -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Hi Bert.
I need to close the connection after sending the last message. At a certain message length the disconnect happens before the message was send completely. That's why i thought putting the disconnect via post to the io service will handle this. But this is not the case. How can i make a clean disconnect when all outstanding messages were send completely??
We model our connection's state using a state machine (boost::statechart rocks :-)) and in this case we would have a state 'sending data' which would simply defer the 'regular disconnect' event until the next 'sending done' state. Second thing that pops to mind is that your large messages may get fragmented when sending them and you need to send the rest of the message again after getting notified that the first part got sent. Then you need to leave the 'sending data' state only after the whole message gets sent. Third thing that pops to mind that you need to be able to handle 'dirty disconnect' events in any state caused by any sort of network failure. Among other things this requires that the final 'disconnected' state ignores any further events that might have gotten posted after the 'dirty disconnect' event but before that event got processed. And so on, and so on... :-) An endless source of border-conditions to look out for... :-))) Hope this helps... Best regards, Jurko Gospodnetić
participants (2)
-
Bert Passek
-
Jurko Gospodnetić