Re: [Boost-users] [beast] I can't write a hello world server
(Trying to repost because the previous message was rejected due to size limits.) Hi Loup, The reason I'm taking the time to ask here is because I feel there is something fundamental, likely obvious to the experts, that I don't understand about how beast (and, I'm guessing, asio) works, and how I'm supposed to use it. It seems like you are quite comfortable with C++. That is good because it is a necessary background for this. Boost.Asio and .Beast are inherently advanced topics. The examples use quite advanced C++ knowledge. It could appear simple to experts who understand asio and C++, as well as to newcomers if they were lucky to get the right orientation when they began to learn C++. I had to unlearn a lot of 'C' and old C++ notions. Here are some resources that helped me reach the Aha! moment after a lot of struggles. They are all well worth the patient time you will need. (They are from my bookmarks and are a bit dated. You can easily get the corresponding latest versions.) 1. ASIO: https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio.html 2. Beast: Watch this video https://youtu.be/7FQwAjELMek at the bottom of the tutorials page https://www.boost.org/doc/libs/1_80_0/libs/beast/doc/html/beast/examples.htm.... This video was a turning point for me. 3. If you would like interactive help, join the #beast channel of the cpplang slack https://cppalliance.org/slack/. They are very kind and super helpful. When you get asio and beast to work well, they are beautiful and give you joy. HTH. Thanks, Senthil.
Hi Senthil, thanks for the kind reply.
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://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://youtu.be/7FQwAjELMek at the bottom of the tutorials page https://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://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://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.
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.
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.
Yeah, I didn't know about boost::asio::post() until yesterday. Looks like this is the way, thanks.
Please review http_server_async.cpp and websocket_server_async.cpp files in the examples page.
Will do. Loup.
participants (2)
-
Loup VAILLANT -
Senthil Cheetancheri