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 <<a href=3D"mailto:boost-= [email protected]">[email protected]</a>> 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'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 "on_immediate()" 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 "on_immediate()" 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==--