[Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway
Pablo Esteban Camacho <[email protected]> Sat, 30 Sep 2023 04:34:34 -0600
| Newsgroups | gmane.comp.parsers.spirit.devel,gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <CALj9gz2cGvsj-wAnVMzqQ8O3_89rQfbpAZXTZsS_rdCzy6LrbQ@mail.gmail.com> |
--===============4867190752109983634== Content-Type: multipart/alternative; boundary="000000000000634b5706069118ec" --000000000000634b5706069118ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *[Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway* Dear Sirs: 1. I am a C++ Developer. Neither a Boost.Asio developer expert, nor a networking expert. 2. I have now the opportunity to develop a networking application from scratch, which requires interaction with an already existing application. 3. The already existing application seems to have been developed entirely in C language, with Linux-based networking header files (source code is not yet available to me). 4. My first understanding (or, more precisely, my assumption) is that each and every networking solution that can be implemented in C language can also be implemented in C++, using Boost.Asio. 5. However, reviewing again the Boost.Asio documentation, I am prone to understand that "Asio" might be an acronym for: "ASinchronous Input-Output". If this is correct, maybe, synchronous implementations might be out of the scope of Boost.Asio. 6. Since the application I have to develop needs to interact with an already existing application, I also need to discuss my solution with external stakeholders who are experts on that already existing application. 7. Now, even though I have the entire decision to choose the development tools for this new application (my managers are "networking" architects; not software architects; so, they rely entirely on my own decision), I need to provide a precise fundament for my election. 8. Starting on my assumption posted in # 4, I want to develop a modern C++ networking robust application, using Boost.Asio and rejecting a C solution, if possible; of course. 9. As my managers are not software experts, they are not able to provide precise business requirements to me, valuable to making the correct decision. 10. Instead, to know even the business requirements of the new application, it seems that I need to rely on the external stakeholders (mentioned in # 6). 11. I presented my intention of using Boost.Asio to one of those external stakeholders and received the following response from him: > About using Boost.Asio library: > 1) Following our meeting, I did a quick dive into the documentation provided on https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview.html. > 2) I don=E2=80=99t have really some experience with Boost; but it seems t= o me that the networking part of this library [Boost.Asio] is fully oriented towards building an application server, i.e. allowing agents/clients to connect to the machine running Boost.Asio and allowing the program to process a result in an asynchronous way, and then return a result (e.g. by responding to the same network socket). Boost.Asio might be useful to build e.g. an HTTP server or a REST API server. > 3) Boost.Asio seems to rely on the networking capabilities of the OS ["operating system"] (e.g. Sockets) to get the data from the received packets, manage TCP connections handshakes, opening, and closing (which implies packet copy between kernel land and user land, impairing global performance). > 4) In those cases, Boost.Asio seems to manage communications from a client and intended for the server running the program. > 5) Instead, the application you want to build is actually quite different from that behaviour, as the machine will not be the =E2=80=9Cdestination=E2= =80=9D of those packets, but just a gateway. That means that the packets received on the NIC ["network interface controller"] shall not be fully interpreted by the OS, since the OS is not the recipient of the packet. > 6) Moreover, you cannot start an asynchronous operation per packet found on the wire, as this will overload the system. > 7) So the "packet acquisition" / "thread dispatching" for the traffic management of your application seems actually not be manageable by Boost.Asio library. > 8) As a consequence, my view is that you will have to manage the "packet acquisition" / "thread dispatching" / "per thread packet processing" in a dedicated synchronous architecture (as built in our code samples). And then, the result of the DPI ["deep packet inspection"] analysis can be a "starting point event" (or allow to launch an "initiating function") for further asynchronous mechanism run by Boost.Asio to perform operations based on DPI results (and containing the specific logic of your application). > 9) As indicated in the beginning, I=E2=80=99m not a Boost.Asio expert, so= please tell me if my understanding is wrong. 12. First of all, I want to clarify that I arrived to know all the content of the quoted email via that email and not before. That is: even the requirements of the "dedicated synchronous architecture" were provided to me in that email, "as if I was aware of them before that email". 13. Now, as you can understand, I cannot start a long development path ending at the middle of it saying: "We made a wrong assumption. We cannot use Boost.Asio. We need to turn back on our own steps and start all over again with a different approach". This would be unacceptable. 14. And it would be more unacceptable with the previous quoted email coming from a person that, even he is not a Boost.Asio expert, he is an expert on his own already existing application and seems to be the referent, so far, for my own requirements. 15. Even though we are at a very early stage (where I have not even access to the existing source code, as mentioned), a response on this topic is expected from my side. 16. Consequently, given the corresponding context, I am presenting now my questions: A. Is it correct my assumption that: each and every networking solution that can be implemented in C language can also be implemented in C++, using Boost.Asio? B. Or, is it correct my assumption that synchronous implementations might be out of scope of Boost.Asio? C. If question A. is correct, then, is it possible to use Boost.Asio for a dedicated networking synchronous architecture and implementation where the Operating System is just a gateway (as described in the quoted email)? D. Or the suggested opinion of the quoted stakeholder is correct? E. In case the quoted stakeholder is not correct on his assumption, do we have enough available documentation about Boost.Asio to implement a solution with the main topics described in question C.? F. Or, in case the quoted stakeholder is correct on his assumption: are you aware of an advisible library on top of which I might be able to develop the requested solution using modern C++, to avoid relying on a C solution? In advance, I appreciate very much your answers, help, and precise advice! Pablo Esteban Camacho C & C++ Developer [email protected] [email protected] https://www.linkedin.com/in/pablo-esteban-camacho/ --000000000000634b5706069118ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><b>[Boost.Asio] suggested to not be useful for a dedicated= networking synchronous implementation where the Operating System is just a= gateway</b><br><br>Dear Sirs:<br>1. I am a C++ Developer. Neither a Boost.= Asio developer expert, nor a networking expert.<br>2. I have now the opport= unity to develop a networking application from scratch, which requires inte= raction with an already existing application.<br>3. The already existing ap= plication seems to have been developed entirely in C language, with Linux-b= ased networking header files (source code is not yet available to me).<br>4= . My first understanding (or, more precisely, my assumption) is that each a= nd every networking solution that can be implemented in C language can also= be implemented in C++, using Boost.Asio.<br>5. However, reviewing again th= e Boost.Asio documentation, I am prone to understand that "Asio" = might be an acronym for: "ASinchronous Input-Output". If this is = correct, maybe, synchronous implementations might be out of the scope of Bo= ost.Asio.<br>6. Since the application I have to develop needs to interact w= ith an already existing application, I also need to discuss my solution wit= h external stakeholders who are experts on that already existing applicatio= n.<br>7. Now, even though I have the entire decision to choose the developm= ent tools for this new application (my managers are "networking" = architects; not software architects; so, they rely entirely on my own decis= ion), I need to provide a precise fundament for my election.<br>8. Starting= on my assumption posted in # 4, I want to develop a modern C++ networking = robust application, using Boost.Asio and rejecting a C solution, if possibl= e; of course.<br>9. As my managers are not software experts, they are not a= ble to provide precise business requirements to me, valuable to making the = correct decision.<br>10. Instead, to know even the business requirements of= the new application, it seems that I need to rely on the external stakehol= ders (mentioned in # 6).<br>11. I presented my intention of using Boost.Asi= o to one of those external stakeholders and received the following response= from him:<br><br>> About using Boost.Asio library:<br>> 1) Following= our meeting, I did a quick dive into the documentation provided on <a href= =3D"https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview.html= ">https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview.html</= a>.<br>> 2) I don=E2=80=99t have really some experience with Boost; but = it seems to me that the networking part of this library [Boost.Asio] is ful= ly oriented towards building an application server, i.e. allowing agents/cl= ients to connect to the machine running Boost.Asio and allowing the program= to process a result in an asynchronous way, and then return a result (e.g.= by responding to the same network socket). Boost.Asio might be useful to b= uild e.g. an HTTP server or a REST API server.<br>> 3) Boost.Asio seems = to rely on the networking capabilities of the OS ["operating system&qu= ot;] (e.g. Sockets) to get the data from the received packets, manage TCP c= onnections handshakes, opening, and closing (which implies packet copy betw= een kernel land and user land, impairing global performance).<br>> 4) In= those cases, Boost.Asio seems to manage communications from a client and i= ntended for the server running the program. =C2=A0<br>> 5) Instead, the = application you want to build is actually quite different from that behavio= ur, as the machine will not be the =E2=80=9Cdestination=E2=80=9D of those p= ackets, but just a gateway. That means that the packets received on the NIC= ["network interface controller"] shall not be fully interpreted = by the OS, since the OS is not the recipient of the packet.<br>> 6) More= over, you cannot start an asynchronous operation per packet found on the wi= re, as this will overload the system.<br>> 7) So the "packet acquis= ition" / "thread dispatching" for the traffic management of = your application seems actually not be manageable by Boost.Asio library.<br= >> 8) As a consequence, my view is that you will have to manage the &quo= t;packet acquisition" / "thread dispatching" / "per thr= ead packet processing" in a dedicated synchronous architecture (as bui= lt in our code samples). And then, the result of the DPI ["deep packet= inspection"] analysis can be a "starting point event" (or a= llow to launch an "initiating function") for further asynchronous= mechanism run by Boost.Asio to perform operations based on DPI results (an= d containing the specific logic of your application).<br>> 9) As indicat= ed in the beginning, I=E2=80=99m not a Boost.Asio expert, so please tell me= if my understanding is wrong.<br><br>12. First of all, I want to clarify t= hat I arrived to know all the content of the quoted email via that email an= d not before. That is: even the requirements of the "dedicated synchro= nous architecture" were provided to me in that email, "as if I wa= s aware of them before that email".<br>13. Now, as you can understand,= I cannot start a long development path ending at the middle of it saying: = "We made a wrong assumption. We cannot use Boost.Asio. We need to turn= back on our own steps and start all over again with a different approach&q= uot;. This would be unacceptable.<br>14. And it would be more unacceptable = with the previous quoted email coming from a person that, even he is not a = Boost.Asio expert, he is an expert on his own already existing application = and seems to be the referent, so far, for my own requirements.<br>15. Even = though we are at a very early stage (where I have not even access to the ex= isting source code, as mentioned), a response on this topic is expected fro= m my side.<br>16. Consequently, given the corresponding context, I am prese= nting now my questions:<br><br>A. Is it correct my assumption that: each an= d every networking solution that can be implemented in C language can also = be implemented in C++, using Boost.Asio?<br>B. Or, is it correct my assumpt= ion that synchronous implementations might be out of scope of Boost.Asio?<b= r>C. If question A. is correct, then, is it possible to use Boost.Asio for = a dedicated networking synchronous architecture and implementation where th= e Operating System is just a gateway (as described in the quoted email)?<br= >D. Or the suggested opinion of the quoted stakeholder is correct?<br>E. In= case the quoted stakeholder is not correct on his assumption, do we have e= nough available documentation about Boost.Asio to implement a solution with= the main topics described in question C.?<br>F. Or, in case the quoted sta= keholder is correct on his assumption: are you aware of an advisible librar= y on top of which I might be able to develop the requested solution using m= odern C++, to avoid relying on a C solution?<br><br>In advance, I appreciat= e very much your answers, help, and precise advice!<br><br><br>Pablo Esteba= n Camacho<br>C & C++ Developer<br><a href=3D"mailto:pablo.esteban.camac= [email protected]">[email protected]</a><br><a href=3D"mailto:pabl= [email protected]">[email protected]</a><br><a href=3D"https://www.= linkedin.com/in/pablo-esteban-camacho/">https://www.linkedin.com/in/pablo-e= steban-camacho/</a><br></div> --000000000000634b5706069118ec-- --===============4867190752109983634== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4867190752109983634== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Spirit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spirit-devel --===============4867190752109983634==--