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

Client sender handle idle timeout #187

Open
ndanzi opened this issue Oct 4, 2017 · 3 comments
Open

Client sender handle idle timeout #187

ndanzi opened this issue Oct 4, 2017 · 3 comments
Assignees

Comments

@ndanzi
Copy link

ndanzi commented Oct 4, 2017

Hi,

I'm using your library for an amqp client with iothub.
When I have to send a message i build it and I call the connection_dowork function in order to process the message. When I receive the callback that the message has been sent, I exit the connection_dowork loop.
Then I wait for another message to be sent.

In this way I noticied that the idle timeout is not handled. No empty frame is sent to the broker within the idle timeout that the server sent to me. And no check is done in order to close the connection if the server does not send the white frame whithin the idle timeout that I specified.

My idea is to create a thread with a while-true loop that calls the connection_dowork. In this way messages to be sent and idle timeout are both handled.
Is this the pattern with which the library is meant to be used?
Are there other functions or options that handle idle timeout automatically after the connection is opened?

Another question: is there a way to get the remote_idle_timeout that the server sent to me?

Thank you in advance for attention
Nicolo'

@ndanzi
Copy link
Author

ndanzi commented Oct 4, 2017

Another question: is there a callback that indicates that the white frame has been sent successfully by the client?

@dcristoloveanu
Copy link
Member

Hi @ndanzi

Thanks for the issue and sorry for the delay on my side.
You are correct, the _dowork function does all the work that the library needs and it needs to be scheduled by the user whenever the user thinks it is appropriate.

Typically it is enough to have a thread that calls do work and yields for a couple of ms (1 ms might be too tight for you maybe you simply want to have it at 5 ms for example). This time determines basically the latency for incoming messages and idle timeout detection if no other _dowork calls are made in some other parts of the code.

I have in plan to have a select-like/epoll-like mechanism to allow waiting until an event has occurred at the socket level(or timer) rather than forcing a predefined yield time, but until now it did not really get on the priority list.

"Are there other functions or options that handle idle timeout automatically after the connection is opened?"
Nope, connection_dowork handles that.

"is there a way to get the remote_idle_timeout that the server sent to me?"
Unfortunately not. It would not be hard to add, as it simply needs a getter in connection. If you want to add that I'm more than happy to pull it in.

"Another question: is there a callback that indicates that the white frame has been sent successfully by the client?"
There is no such callback right now. Do you have a use case for it being exposed? Also one thing to note here is that empty frames might not be sent at all if enough traffic exists on the connection, so I am not sure if it would be a lot of value for the user application. But I'm open to adding such a callback if a use case exists and it generally makes sense.

Cheers,
/Dan

@dcristoloveanu
Copy link
Member

Marking this as enhancement for a way to get remote_idle_timeout.

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

No branches or pull requests

2 participants