[Boost-users] asio error codes

[Christopher Pisz]

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.

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[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 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?

[Christopher Pisz]

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.

[Andreas Wehrmann]

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...@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.weh...@centersystems.com

[Igor R]

> 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.