Re: [Spirit-general] [Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway
On Sun, Oct 1, 2023, at 5:44 PM, Raymond Burkholder wrote: > But I'll answer here anyway. The stakeholder is probably missing some > important capabilities of ASIO. it can act in sync/async modes. In can act > as a gateway. ASIO can reuse buffers. ASIO can work to reduce the number of > copies made. 100% this. In fact, they also invented some limitations/specializations that are notoriously absent from the library. In fact it can be quite daunting to implement a request handling server in plain Asio (which is why e.g. Boost Beast exists). >> 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? For some value of true, this is always true. Only, at some point you're effectively not using Asio anymore. But you can mix and match, so if you need e.g. lowlevel native access at some point, you can. Notable areas to be wary of is: raw sockets (supported, but harder), rare protocols (TCP/UDP are well facilitated, ICMP and similar can be done with little effort https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview/networking/protocols.html, everything else might require substantial extension work https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview/networking/other_protocols.html) >> B. Or, is it correct my assumption that synchronous implementations might be >> out of scope of Boost.Asio? They are not. But I'll add that it really sounds like you *absolutely* want/need aynchronous operation. Otherwise, you would basically have to resort to thread-per-connection model which just scales badly. >> 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)? The wording "the OS is just a gateway" indicates sloppy specification or even confusion to me. The OS is always just an intermediary. The point seems to rather be that your application is merely a (monitoring?) gateway. Of course it possible, and indeed, quite easy and elegant to implement this with ASIO. With some proper configuration you would even benefit from io_uring if targeting kernel 5.10+: https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview/implementation.html#boost_asio.overview.implementation.linux_kernel_5_10 >> D. Or the suggested opinion of the quoted stakeholder is correct? It's hard to say - it does sound like some aspects are not fully informed. >> 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.? How much documentation is required will largely depend on how much experience with networking code is present - specifically on the target platform >> 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? I don't. To be honest, it feels like any other library will receive the same scepsis from the client's reviewers: it's simply not "how they've always done things" so they will be hesitant. That's just my read - obviously you have been in actual contact with the reviewing engineers so should be in a better position to gauge the situation. >> >> In advance, I appreciate very much your answers, help, and precise advice! Just to highlight things missing from the picture: - this is not an ASIO mailing list. The most actively Asio support channels are cppslack https://cppalliance.org/slack/ - ironically most library experts lurk in the #beast channel. There's also an #asio channel (which might not be public, I don't remember) where Chris Kohlhoff is known to sometimes contribute - you don't describe the functionality of the application, though it seems a bit like you're building a pack-inspecting application proxy. It might even need to be a completely transparent network proxy? Be sure to ascertain which protocols must be supported (see also above), what QoI metrics are to be met. - thinking out of the box, if it's merely inspecting traffic flows, consider building it on iptables/BPF. You can even mock things up with tcpdump-like monitoring tools (or libpcap and friends in your custom code) My $0.02 Seth___ Spirit-general mailing list Spirit-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spirit-general
Re: [Spirit-general] [Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway
I don't think the Spirit mailing list is the correct place for this message. The Boost Developer's list or Boost General list , or the live Slack forums are probably more appropriate. But I'll answer here anyway. The stakeholder is probably missing some important capabilities of ASIO. it can act in sync/async modes. In can act as a gateway. ASIO can reuse buffers. ASIO can work to reduce the number of copies made. It may be an issue of premature optimization to start worrying about how may many times copies are made. it may be more useful to quickly prototype something with ASIO so that you can get a grip on where the hot paths are, and then optimize from there. DPI more CPU intensive and latency prone than are some of the other operations you are discussing. The one thread per packet isn't the model. ASIO works with a worker thread model. So you can optimize the number of work threads depending on packet processing and how you want to group them. In addition, if you really want to get into the guts of packet delivery, then you probably want to consider the integration of eBPF into your overall workflow (where processing can be handled in the kernel, without context switching). And then, if you get into higher delivery rates, you may want to deal with packet processing offload into the NIC hardware, ... ie spread load across hardware, kernel, and app. If you want to bypass kernel processing, then look at DPDK which handles packets totally in user space. There are many other combinations of packet processing, all dependent on how something is going to be priced and how much hardware you can throw at the problem. On 9/30/23 04:34, Pablo Esteban Camacho wrote: *[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’t have really some experience with Boost; but it seems to 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
[Spirit-general] [Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway
*[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’t have really some experience with Boost; but it seems to 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 “destination” 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’m 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
