Hey Ben, I guess the issue is less with RequestTransactionManager (RTM) and more with race condition between client connections. What concurrency level do you have? The transaction id can be incremented independently in driver using atomic long/int. Processing of transactions is always within submission order. It you calculate transaction id within transaction task then it will be consistent.
Best, Łukasz Dywicki -- Code-House http://code-house.org > On 3 May 2021, at 12:15, Ben Hutcheson <[email protected]> wrote: > > Hi, > > I have been working on a native driver for OPCUA and am seeing an issue > with the ordering of messages sent over the wire. > > For each message that gets sent over the wire, A transaction ID is assigned > to it. These transaction IDs need to be received by the server in order. At > the moment I'm using (Well planning on using) the RequestTransactionManager > class to assign the ID. > > A typical sequence is:- > > 1. I request the ID > 2. create the message > 3. encrypt the message > 4. submit it to be sent > > However between creating the ID and sending it, it leaves it open for > another message from a separate thread to be sent with a later transaction > ID. This would result in the server ignoring the out of sequence messages. > > Looking at the RequestTransactionManager class it seems to retain the order > of when the message is submitted and not the transaction id order. I have a > couple of options and am looking for some feedback:- > > - Change the RequestTransactionManager class so that it processes the > requests in the transaction ID order instead of the submitted order. > - Create a class that retains the transaction id order. > - Modify the RequestTransactionManager to have the option between the > two. > > I'd prefer modifying the existing class to use the transaction id order, > but don't know enough about the other protocols PLC4X supports to say that > it won't affect them. > > Kind Regards > > Ben
