Hi, May I ask few questions just for clarification of the situation: On Tue, May 20, 2025 at 4:03 PM Nedelin Rusev via Boost-users < boost-users@lists.boost.org> wrote:
> Hi, > > Recently I inherited an old project, which uses boost 1.65.0 and ASIO, for > 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 clients > 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 of > 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 > Boost-users@lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
