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
