Re: [Boost-users] Timeout on read/write using Boost.Asio
hi,
Thanks for your reply.
I cancel the read/write on a tcp connection because the current node I connected to may be too busy to response, so I can try another node.
I do not want cancel all async request because the other pending operations may finish successfully, the workload on peer node is very heavy instead of failure.
Anyway, I can cancel all request, but I still have the question about the cancel.
What if I cancel all the async operation, is there any partial data which has been read from or write to socket after the cancelation?
If partial data has been read from or write to socket, how can I issue both async read/write again?
Best Regards
Zhanwei Wang
----- Original Message -----From: Igor R
My question is: the "cancel" call acutely cancel all the pending async operation, but only one of them is timeout. For example, there is a pending async read and a pending async write operation, only read is timeout, I do not want cancel write any way.
Yes, you're right. You'll have to issue both async read and write again. But usually "timeout" means that something goes wrong with the connection (i.e. you expected something, but it failed to happen). _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
What if I cancel all the async operation, is there any partial data which has been read from or write to socket after the cancelation? If partial data has been read from or write to socket, how can I issue both async read/write again?
Right, some data might have been sent/received, and you have to re-synchronise somehow your client and server. Even if it's possible, it would be pretty complicated. Besides, cancellation is not quite portable: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/basic_str... That's why it's usually a bad idea to cancel operations on a socket. Instead, you can just close the socket and then re-establish connection from scratch.
I cancel the read/write on a tcp connection because the current node I connected to may be too busy to response, so I can try another node. I do not want cancel all async request because the other pending operations may finish successfully, the workload on peer node is very heavy instead of failure.
Well, I don't know what you application does, but I'm afraid it's not the right way to go. First of all, why can't you connect all the "nodes" you need? Anyway, you should decide for every particular connection whether it's ok or "faulty" (returned error, takes too much time, no ping, no heartbeat, etc...): if it's ok - wait for response, if it's faulty - just close it.
participants (2)
-
boost
-
Igor R