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

multiple streams with suspend/resume #43

Open
kunalekawde opened this issue Dec 30, 2018 · 4 comments
Open

multiple streams with suspend/resume #43

kunalekawde opened this issue Dec 30, 2018 · 4 comments

Comments

@kunalekawde
Copy link

Hi ,
When i verified multiple streams with suspend/resume, it doesn't seems to be working. After responding on 1 stream other is not responded. I've seen some todo list wherein its mentioned that it will work for single stream, wanted to confirm if this is the same case. If we have to make it work, can you please provide some inputs on where we should check ?
Thanks

@maru
Copy link
Owner

maru commented Dec 31, 2018

Hello! This is a first alpha release. All details are here:

https://lists.gnu.org/archive/html/libmicrohttpd/2018-03/msg00032.html

This functionality is included in the To Do list:

  • Handle suspend/resume actions correctly (now implemented for only one stream).

@kunalekawde
Copy link
Author

Hi,

I could get multiple stream to work with suspend/resume. Could you please check if this approach is fine:

  1. When a request is received over a stream, connection wont be suspended but some data structures would be updated regarding stream details.
  2. So if multiple requests are received over the connection, only the data structures would be updated to reflect that stream is suspended, the connection/epoll state/epoll list/suspended list not updated or changed.
  3. On resume, the application needs to pass the stream id as well along the connection, here it will update the stream data-structure to indicate that it needs to be resumed and trigger/activate the MHD ITC.
  4. As part of MHD_connection_handle_idle API, it will also monitor the state of the streams i.e. if they were suspended and needs to be resumed.
  5. When the condition is met in Allow Upgrade requests #4, it invokes the MHD access handler callback.
  6. On the callback, when MHD_queue_response is invoked, it would update the epoll state for the connection (epoll state ready & write ready) & invoke MHD_connection_epoll_update_()
  7. In MHD_connection_epoll_update_(), if the connection is http2 it will update the epoll_ctl to epoll_mod instead of epoll_add, which would eventually trigger sending response for this stream.

Thanks,
Kunal

@maru
Copy link
Owner

maru commented Jan 7, 2019

Hello Kunal,
I'm on holidays for the following two weeks, so I won't be able to look into this.
But it's very interesting what you have proposed, so when I'm back I'll discuss it with you!

Regards,
maru

@kunalekawde
Copy link
Author

Thanks Maru, another thing i wanted to confirm is that there are lot of files under src/lib which are like modular parts of MHD, is the code part of this lib folder used ? I tried daemon_epoll.c to see if API's are invoked external but couldn't figure out also verified with debug log. Please let me know if that folder is relevant.

Thanks,
Kunal

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

No branches or pull requests

2 participants