I am simply relaying what I have read from experienced FIX programmers who, having put up with these problems, invented the DTC protocol in the first place.

On a side note, I wrote the Ally Plugin, which used a small number of FIX messages in a special XML format called FIXML, jumbled with their own proprietary REST stuff. And none of the FIXML messages were actually compliant with the official FIXML schema! Ally ignored me when I asked about it.

But that was a mixed interface. Hopefully I won’t have such hiccups working with pure FIX. None!

Andrew, FIX messages are asynchronous, correct? so you manage somehow concurrency when callbacks from FIX gain access to the same shared resources?

Thanks

Asynchronous network programming would be the preferred approach, yes, but technically it can be programmed synchronously as well, and optionally multithreaded (not necessarily the same thing as asynchronous). A server can send several kinds of messages at any time, so a plugin will need to receive and handle them. Let your programmer decide the best approach.

thanks Andrew, so you would suggest as a possible solution the plugin 'receiver' to collect callbacks, queue them and send for processing sequentially one by one. correct?

thanks

Messages should always be sent and received on a FIFO basis, yes.