Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

handling end_of_stream errors #2045

Closed
ashjas opened this issue Aug 5, 2020 · 4 comments
Closed

handling end_of_stream errors #2045

ashjas opened this issue Aug 5, 2020 · 4 comments
Labels
Stale No recent activity

Comments

@ashjas
Copy link

ashjas commented Aug 5, 2020

Beast version 1.71

Hello,

we are using the async version of client for REST communication.
The server keeps on closing the alive connections, at specific intervals, which isint in our control.
This results in end_of_stream error at on_write().

We have encapsulated the connect sessions say class beastsession; which includes:

    io_strand& m_strand;
    tcp::resolver m_resolver;
    beast::tcp_stream m_stream;
    beast::flat_buffer m_buffer;

There is another class which manages these sessions, and their cleanups.
say class Manager;

The issue we need to avoid is that in async flow, the end_of_stream should be handled gracefully within a single async initiate operation, so that , the user does not have to deal with retries in its code.

We are checking the socket state in class Manager using stream.socket().is_open(), and if it returns true, we assume that the connection would be valid, and we reuse this connect session, but which ultimately ends up in end_of_stream error.

How can i check something else along with stream.socket().is_open() so that we can get to know if the write call would end up in end_of_stream error or in other words, that the server has already closed on this alive connection, so as to discard the session and create a new session for this request before attempting anything with the old session?

@madmongo1
Copy link
Collaborator

The problem with testing state before making a call is that the state can change during the call or during the write. Remember that the FIN packet sent by the server to close the TCP connection can arrive at any time.

Therefore the only reliable way to handle the case where the tcp session has been closed is to attempt the send, and on the first error, re-connect and resend.

You would then want to propagate subsequent errors back to the caller.

In actual fact, the asio is_open() method merely tests to see whether the underlying socket handle is a valid socket FD (i.e. created with the sockets library call socket() .

ref: https://www.man7.org/linux/man-pages/man2/socket.2.html

@stale
Copy link

stale bot commented Sep 5, 2020

This issue has been open for a while with no activity, has it been resolved?

@stale stale bot added the Stale No recent activity label Sep 5, 2020
@stale
Copy link

stale bot commented Sep 12, 2020

It looks like this issue has either been abandoned or resolved so I will go ahead and close it. Feel free to re-open this issue if you feel it needs attention, or open new issues as needed. Thanks!

@stale stale bot closed this as completed Sep 12, 2020
@stale
Copy link

stale bot commented Sep 20, 2020

It looks like this issue has either been abandoned or resolved so I will go ahead and close it. Feel free to re-open this issue if you feel it needs attention, or open new issues as needed. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale No recent activity
Projects
None yet
Development

No branches or pull requests

2 participants