What I need is a way for the user-code to yield, and then resume later when it has the info it needs to build the response.
I used beast::websocket to keep the https connection open with a client and used boost::asio::post() on the server. This way, a worker thread on the server can submit a job for processing and go listen for new incoming requests. Some worker thread will be called-back to run a completion function when the response is ready.
I am sure there are other ways to achieve this.
Please review http_server_async.cpp and websocket_server_async.cpp files in the examples page.
HTH.
Thanks,
Senthil.
________________________________
From: Loup VAILLANT
It seems like you are quite comfortable with C++.
I am, though I'm lagging behind the latest standard (I have given up actively keeping up after C++14, now I just look up what I need).
Boost.Asio and .Beast are inherently advanced topics. The examples use quite advanced C++ knowledge.
To be honest it didn't felt like they are. For the Asio and Beast _implementers_, sure, but the user code of the smallest examples felt relatively simple (though perhaps with a few tricks here and there I didn't know about std::enable_shared_from_this for instance). But if I'm mistaken, and Asio and Beast require advanced knowledge from the _user_, that's a… let's say a significant disadvantage.
1. ASIO: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_79_0%2Fdoc%2Fhtml%2Fboost_asio.html&data=05%7C02%7Cscheetancheri%40SonicWall.com%7C076da0c27cb74fbccc9a08dc58931dab%7C84fe6f401cbc473083288018b2af88bc%7C1%7C0%7C638482636683026819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=cdakAOtewm1PoM65dccpo829Luh5%2BJWl9E8QueTBae8%3D&reserved=0https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio.html
Looking it up right now, thanks.
2. Beast: Watch this video https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F7FQwAjELMek&data=05%7C02%7Cscheetancheri%40SonicWall.com%7C076da0c27cb74fbccc9a08dc58931dab%7C84fe6f401cbc473083288018b2af88bc%7C1%7C0%7C638482636683035454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=E8CPPtP%2BpF%2BwLSIK3rnmoSUflIomiMokmm5ON91%2BR5o%3D&reserved=0https://youtu.be/7FQwAjELMek at the bottom of the tutorials page https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_80_0%2Flibs%2Fbeast%2Fdoc%2Fhtml%2Fbeast%2Fexamples.html&data=05%7C02%7Cscheetancheri%40SonicWall.com%7C076da0c27cb74fbccc9a08dc58931dab%7C84fe6f401cbc473083288018b2af88bc%7C1%7C0%7C638482636683040581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=evHYnCP4CUCgpbC%2FrOuAwmKcf%2F4lfGVvXUlD5AHYMg0%3D&reserved=0https://www.boost.org/doc/libs/1_80_0/libs/beast/doc/html/beast/examples.htm.... This video was a turning point for me.
I've watched it too. It did help a bit, though not as much as I'd hope. One little thing however felt positively alarming: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D7FQwAjELMek%26t%3D2888s&data=05%7C02%7Cscheetancheri%40SonicWall.com%7C076da0c27cb74fbccc9a08dc58931dab%7C84fe6f401cbc473083288018b2af88bc%7C1%7C0%7C638482636683046524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=Qc3a%2FNmt8cHzf8zREnvkfWbNorAr%2FtybrknrK1USPIM%3D&reserved=0https://www.youtube.com/watch?v=7FQwAjELMek&t=2888s """ Write as much code as you can. The more you'll write the better you'll get […]""" As a general advice to anyone learning to program, sure. But so much effort to use an _HTTP library_? That's backwards. To the extent possible, the onus is on the _author_ to make user's life as easy as possible, it's just a better use of our collective cognitive resources. But maybe he was referring to deeper concepts like asynchronous operations, and for such transferable skills I do agree we users should invest time.
3. If you would like interactive help, join the #beast channel of the cpplang slack https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcppalliance.org%2Fslack%2F&data=05%7C02%7Cscheetancheri%40SonicWall.com%7C076da0c27cb74fbccc9a08dc58931dab%7C84fe6f401cbc473083288018b2af88bc%7C1%7C0%7C638482636683051569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=gWGRQnCUKYGkUDJ8dVDlA0%2B4UHS9TWGcnHMAUlEDnIY%3D&reserved=0https://cppalliance.org/slack/. They are very kind and super helpful.
I'll check it out if I can, thanks. In the mean time I have one remaining question: For the application I'm currently writing, I survived until now with just replying immediately: get request, build respond, send, done. Soon however I will need to wait for messages across the internet to build my responses. Which is a bit of a problem. I've just tested adding an active sleep for several seconds in my user-side respond() function, and noticed it effectively blocked further requests (there was no concurrent requests). What I need is a way for the user-code to yield, and then resume later when it has the info it needs to build the response. Is there a quick answer to that, or is this a "no royal road to Asio" situation? Loup.