Re: Boost:1.82.0 ASIO changed its behavior

Pavel Vazharov via Boost-users <[email protected]> Wed, 21 May 2025 07:04:39 +0300
Newsgroups gmane.comp.lib.boost.user
Message-ID <CAK9EM1886Ud0fNxgzYc0E8bqcAt7E9vU0XostP_LQ8xSXsJYOg@mail.gmail.com>
--===============7010632687939358417==
Content-Type: multipart/alternative; boundary="00000000000094ae2606359d774a"

--00000000000094ae2606359d774a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,
May I ask few questions just for clarification of the situation:
On Tue, May 20, 2025 at 4:03=E2=80=AFPM Nedelin Rusev via Boost-users <
[email protected]> wrote:

> Hi,
>
> Recently I inherited an old project, which uses boost 1.65.0 and ASIO, fo=
r
> custom implementation of the SCTP protocol.
> Technically it adapts the existing ASIO TCP for SCTP. Another
> implementation uses this ASIO-SCTP to asynchronously send
> and receive data. My task was to make both implementations work with any
> boost version from 1.65.0 to 1.87.0.
>
> I did the necessary changes and the project now compiles and runs, but I
> face a test deviation with boost versions
> 1.82.0 and above.
>
> The test is more or less simple:
> - we have pre-generated data
> - we start a server, which only receives data and stores it in file per
> connected client
> - we start multiple clients, each running in its own thread. Each client
> sends its own data to the server at a random moment
> - finally we check if the server has received the same data as the client=
s
> have sent.
>
 How does the server receives the data from a particular client:
- Does it receive the data from a single client in different threads? And
if so, does it use a strand for the receiving?
- Or maybe the server distributes the client sessions to separate
executors/io_contexts/threads and thus no synchronization/strands are
needed for the receiving?

>
> With boost versions up to 1.81.0 the test passes OK. But with boost
> version 1.82.0 we observe wrong order of the data stored
> by the server. To illustrate it roughly:
> Client sends:  0,1,2
> Server stores: 0,2,1 (0 is OK, Next we should have 1, but we get 2).
> Note: the real test data is hundreds of bytes long, not single digits.
> Note: the test seems to have issues, but on the particular machine, the
> behavior is consistent:
>       test is OK with boost 1.81.0 and NOK with boost 1.82.0
>
Do you mean that a single client sends 0,1,2 sequences of data or multiple
clients do that? (I understand that it's just an example of the real data).

>
> I suspect the problem has something to do with the "on_immediate()"
> extension, introduced in boost 1.82.0.
> Somehow it speeds up the client threads execution and changes the order o=
f
> the sent data.
> I failed to find any similar problems, reported in internet (git, boost
> forums, etc)
>
> I have enabled BOOST_ASIO_ENABLE_HANDLER_TRACKING and, if I get the log
> right, client threads are executed faster.
> I have attached the handler tracking logs for boost versions 1.81.0 and
> 1.82.0.
>
> My question is how to keep the old code behavior (pre 1.82.0) with later
> versions?
> Is there any way to disable the "on_immediate()" functionality?
> Are there any guidelines for using later versions of boost ASIO (1.82.0
> and later)?
>
>
> Providing a simplified example test is hard, as the code-base is quite
> large.
> I will try to make something up, but this will take time.
>
> Thank you!
> _______________________________________________
> Boost-users mailing list
> [email protected]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>

--00000000000094ae2606359d774a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote gmail_quo=
te_container"><div dir=3D"ltr" class=3D"gmail_attr">Hi,<br>May I ask few qu=
estions just for clarification of the situation:<br>On Tue, May 20, 2025 at=
 4:03=E2=80=AFPM Nedelin Rusev via Boost-users &lt;<a href=3D"mailto:boost-=
[email protected]">[email protected]</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi,<br><=
br>Recently I inherited an old project, which uses boost 1.65.0 and ASIO, f=
or custom implementation of the SCTP protocol.<br>Technically it adapts the=
 existing ASIO TCP for SCTP. Another implementation uses this ASIO-SCTP to =
asynchronously send<br>and receive data. My task was to make both implement=
ations work with any boost version from 1.65.0 to 1.87.0.<br><br>I did the =
necessary changes and the project now compiles and runs, but I face a test =
deviation with boost versions<br>1.82.0 and above.<br><br>The test is more =
or less simple:<br>- we have pre-generated data<br>- we start a server, whi=
ch only receives data and stores it in file per connected client<br>- we st=
art multiple clients, each running in its own thread. Each client sends its=
 own data to the server at a random moment<br>- finally we check if the ser=
ver has received the same data as the clients have sent.<br></div></blockqu=
ote><div>=C2=A0How does the server receives the data from a particular clie=
nt:<br></div><div>- Does it receive the data from a single client in differ=
ent threads? And if so, does it use a strand for the receiving?<br></div><d=
iv>- Or maybe the server distributes the client sessions to separate execut=
ors/io_contexts/threads and thus no synchronization/strands are needed for =
the receiving?<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><br>With boost versions up to 1.81.0 the test passes OK. Bu=
t with boost version 1.82.0 we observe wrong order of the data stored<br>by=
 the server. To illustrate it roughly:<br>Client sends: =C2=A00,1,2<br>Serv=
er stores: 0,2,1 (0 is OK, Next we should have 1, but we get 2).<br>Note: t=
he real test data is hundreds of bytes long, not single digits.<br>Note: th=
e test seems to have issues, but on the particular machine, the behavior is=
 consistent:<br>=C2=A0 =C2=A0 =C2=A0 test is OK with boost 1.81.0 and NOK w=
ith boost 1.82.0<br></div></blockquote><div>Do you mean that a single clien=
t sends 0,1,2 sequences of data or multiple clients do that? (I understand =
that it&#39;s just an example of the real data). <br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>I suspect the proble=
m has something to do with the &quot;on_immediate()&quot; extension, introd=
uced in boost 1.82.0.<br>Somehow it speeds up the client threads execution =
and changes the order of the sent data.<br>I failed to find any similar pro=
blems, reported in internet (git, boost forums, etc)<br><br>I have enabled =
BOOST_ASIO_ENABLE_HANDLER_TRACKING and, if I get the log right, client thre=
ads are executed faster.<br>I have attached the handler tracking logs for b=
oost versions 1.81.0 and 1.82.0.<br><br>My question is how to keep the old =
code behavior (pre 1.82.0) with later versions?<br>Is there any way to disa=
ble the &quot;on_immediate()&quot; functionality?<br>Are there any guidelin=
es for using later versions of boost ASIO (1.82.0 and later)?<br><br><br>Pr=
oviding a simplified example test is hard, as the code-base is quite large.=
<br>I will try to make something up, but this will take time.<br><br>Thank =
you!<br></div>
_______________________________________________<br>
Boost-users mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Boost-user=
[email protected]</a><br>
<a href=3D"https://lists.boost.org/mailman/listinfo.cgi/boost-users" rel=3D=
"noreferrer" target=3D"_blank">https://lists.boost.org/mailman/listinfo.cgi=
/boost-users</a><br>
</blockquote></div></div>

--00000000000094ae2606359d774a--

--===============7010632687939358417==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Boost-users mailing list
[email protected]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

--===============7010632687939358417==--