I am implementing tcp conections using boost asio. I don't see in the documentation anything that says which error code could result from the various asynchronous calls. Obviously, I would have to identify all connection related error codes and set the state of my process such that a reconnect was the way to handle it. In some cases a retry might be needed. However, I don't see a way to get a list of the possible error codes that need to get checked for aside from hours and hours of debugging trial and error. Does there exist somewhere a list of error codes that could result from async_read? which would I get from async_write?, async_accept? etc..etc. I see it is a sytem::error_code, and I can look at the header, I can even find a doc that lists all of them and see asio has a group, but I can't tell which might occur when.
I don't see in the documentation anything that says which error code could result from the various asynchronous calls.
Obviously, I would have to identify all connection related error codes and set the state of my process such that a reconnect was the way to handle it. In some cases a retry might be needed. However, I don't see a way to get a list of the possible error codes that need to get checked for aside from hours and hours of debugging trial and error.
Does there exist somewhere a list of error codes that could result from async_read? which would I get from async_write?, async_accept? etc..etc.
I see it is a sytem::error_code, and I can look at the header, I can even find a doc that lists all of them and see asio has a group, but I can't tell which might occur when.
Most of error_code values come from the lower levels and they are just translated/propagated by asio to your application, so the error you get is not even platform-independent, i.e. on some platform you can get one error, while in the same situation on another platform you might get another error. But does it really affect states in your progam? Why is it important for your state-machine whether you get 10053, 10054 or 10060 error code?
Igor R
I don't see in the documentation anything that says which error code could result from the various asynchronous calls.
Obviously, I would have to identify all connection related error codes and
the state of my process such that a reconnect was the way to handle it. In some cases a retry might be needed. However, I don't see a way to get a
set list
of the possible error codes that need to get checked for aside from hours and hours of debugging trial and error.
Does there exist somewhere a list of error codes that could result from async_read? which would I get from async_write?, async_accept? etc..etc.
I see it is a sytem::error_code, and I can look at the header, I can even find a doc that lists all of them and see asio has a group, but I can't tell which might occur when.
Most of error_code values come from the lower levels and they are just translated/propagated by asio to your application, so the error you get is not even platform-independent, i.e. on some platform you can get one error, while in the same situation on another platform you might get another error. But does it really affect states in your progam? Why is it important for your state-machine whether you get 10053, 10054 or 10060 error code?
Well, my main concern is for reads and writes over tcp. Determining if my connection has been dropped or is unrecoverable, or if I should retry the read or write. I see lots of 'no so self explanatory' error codes in the list of possibles. Such as, "Operation already in progress" "access_denied" "operation_aborted" knowing when and why these occur dictates how I would handle them and whether I'd give up or retry.
On 10/05/2011 12:30 AM, Christopher Pisz wrote:
Well, my main concern is for reads and writes over tcp. Determining if my connection has been dropped or is unrecoverable, or if I should retry the read or write.
I see lots of 'no so self explanatory' error codes in the list of possibles. Such as, "Operation already in progress" "access_denied" "operation_aborted"
knowing when and why these occur dictates how I would handle them and whether I'd give up or retry.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
The usual way to find out whether a TCP connection is "broken" or not is to facilitate a high level heartbeat mechanism. By "high level" I mean the application layer. At least that's how I do it :-) Regards -- Dipl.-Ing. (FH) Andreas Wehrmann Software Development -------------------------------------------------------------- Center Communication Systems GmbH A-1210 Wien, Ignaz-Köck-Straße 19 Sitz in Wien FN 796 88p, Firmenbuchgericht Wien www.centersystems.com Tel.: +43 (0) 190 199 - 3616 Mobile: +43 (0) 664 884 75916 Fax: +43 (0) 190 199 - 2110 E-Mail: a.wehrmann@centersystems.com
Well, my main concern is for reads and writes over tcp. Determining if my connection has been dropped or is unrecoverable, or if I should retry the read or write.
I see lots of 'no so self explanatory' error codes in the list of possibles. Such as, "Operation already in progress" "access_denied" "operation_aborted"
knowing when and why these occur dictates how I would handle them and whether I'd give up or retry.
I don't think you can recover from unexpected errors coming from tcp, by just "retrying read or write". The only thing you can do in any case is to try and re-establish connection.
participants (3)
-
Andreas Wehrmann -
Christopher Pisz -
Igor R