Re: [Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway
Seth via Spirit-general <[email protected]> Sun, 01 Oct 2023 20:36:57 +0200
| Newsgroups | gmane.comp.parsers.spirit.general |
|---|---|
| Message-ID | <[email protected]> |
--===============6975408817780275197==
Content-Type: multipart/alternative;
boundary=55632d55847a468996ab45dfb0c39849
--55632d55847a468996ab45dfb0c39849
Content-Type: text/plain
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
--55632d55847a468996ab45dfb0c39849
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sun, Oc=
t 1, 2023, at 5:44 PM, Raymond Burkholder wrote:<br></div><blockquote ty=
pe=3D"cite" id=3D"qt" style=3D""><div><span class=3D"size" style=3D"font=
-size:13px;"> 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.<br></span></div></bl=
ockquote><div><br></div><div>100% this. In fact, they also invented some=
limitations/specializations that are notoriously absent from the librar=
y. In fact it can be quite daunting to implement a request handling serv=
er in plain Asio (which is why e.g. Boost Beast exists).<br></div><div><=
br></div><div><span class=3D"size" style=3D"font-size:13px;"><br></span>=
</div><blockquote type=3D"cite" id=3D"qt" style=3D""><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div>A. Is it correct my as=
sumption that: each and every networking
solution that can be implemented in C language can also be
implemented in C++, using Boost.Asio?<br></div></div></blockquot=
e></blockquote><div dir=3D"ltr"><div><br></div><div>For some value of tr=
ue, this is always true. Only, at some point you're effectively not usin=
g Asio anymore. But you can mix and match, so if you need e.g. lowlevel =
native access at some point, you can.<br></div><div><br></div><div>Notab=
le areas to be wary of is: raw sockets (supported, but harder), rare pro=
tocols (TCP/UDP are well facilitated, ICMP and similar can be done with =
little effort <a href=3D"https://www.boost.org/doc/libs/1_83_0/doc=
/html/boost_asio/overview/networking/protocols.html">https://www.boost.o=
rg/doc/libs/1_83_0/doc/html/boost_asio/overview/networking/protocols.htm=
l</a>, everything else might require substantial extension work <a=
href=3D"https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overv=
iew/networking/other_protocols.html">https://www.boost.org/doc/libs/1_83=
_0/doc/html/boost_asio/overview/networking/other_protocols.html</a>)</di=
v><div><br></div></div><blockquote type=3D"cite" id=3D"qt" style=3D""><b=
lockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div>B. Or=
, is it correct my assumption that synchronous
implementations might be out of scope of Boost.Asio?<br></div></=
div></blockquote></blockquote><div dir=3D"ltr"><div>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.<br></div><div><br></div></div>=
<blockquote type=3D"cite" id=3D"qt" style=3D""><blockquote type=3D"cite"=
id=3D"qt" style=3D""><div dir=3D"ltr"><div>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)?<br></div></div></blockquote>=
</blockquote><div><br></div><div>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 applicatio=
n is merely a (monitoring?) gateway.<br></div><div><br></div><div>Of cou=
rse it possible, and indeed, quite easy and elegant to implement this wi=
th ASIO. With some proper configuration you would even benefit from io_u=
ring if targeting kernel 5.10+: <a href=3D"https://www.boost.org/do=
c/libs/1_83_0/doc/html/boost_asio/overview/implementation.html#boost_asi=
o.overview.implementation.linux_kernel_5_10">https://www.boost.org/doc/l=
ibs/1_83_0/doc/html/boost_asio/overview/implementation.html#boost_asio.o=
verview.implementation.linux_kernel_5_10</a></div><div><br></div><blockq=
uote type=3D"cite" id=3D"qt" style=3D""><blockquote type=3D"cite" id=3D"=
qt" style=3D""><div dir=3D"ltr"><div>D. Or the suggested opinion of the =
quoted stakeholder is
correct?<br></div></div></blockquote></blockquote><div dir=3D"lt=
r"><div><br></div><div>It's hard to say - it does sound like some aspect=
s are not fully informed.</div><div><br></div></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><blockquote type=3D"cite" id=3D"qt" style=3D"=
"><div dir=3D"ltr"><div>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.?<br></div></div></blockquote></blockquo=
te><div dir=3D"ltr"><div>How much documentation is required will largely=
depend on how much experience with networking code is present - specifi=
cally on the target platform<br></div><div><br></div></div><blockquote t=
ype=3D"cite" id=3D"qt" style=3D""><blockquote type=3D"cite" id=3D"qt" st=
yle=3D""><div dir=3D"ltr"><div>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?<br></div></div></b=
lockquote></blockquote><div dir=3D"ltr"><div>I don't. To be honest, it f=
eels like any other library will receive the same scepsis from the clien=
t'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 actua=
l contact with the reviewing engineers so should be in a better po=
sition to gauge the situation.<br></div><div><br></div></div><blockquote=
type=3D"cite" id=3D"qt" style=3D""><blockquote type=3D"cite" id=3D"qt" =
style=3D""><div dir=3D"ltr"><div><br></div><div>In advance, I appreciate=
very much your answers, help, and
precise advice!<br></div></div></blockquote></blockquote><div><b=
r></div><div>Just to highlight things missing from the picture:<br></div=
><div><br></div><div> - this is not an ASIO mailing list. The most =
actively Asio support channels are cppslack <a href=3D"https://cppa=
lliance.org/slack/">https://cppalliance.org/slack/</a> - 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 Kohlho=
ff is known to sometimes contribute<br></div><div><br></div><div> -=
you don't describe the functionality of the application, though it seem=
s a bit like you're building a pack-inspecting application proxy. It mig=
ht even need to be a completely transparent network proxy? Be sure to as=
certain which protocols must be supported (see also above), what QoI met=
rics are to be met.<br></div><div><br></div><div> - 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 monitorin=
g tools (or libpcap and friends in your custom code)<br></div><div><br><=
/div><div>My $0.02<br></div><div><br></div><div>Seth</div></body></html>
--55632d55847a468996ab45dfb0c39849--
--===============6975408817780275197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============6975408817780275197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general
--===============6975408817780275197==--