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. 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 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!
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
participants (2)
-
Nedelin Rusev -
Pavel Vazharov