Does msmq ensure data integrity on transactional queues?

Question

I'm using MSMQ to transfer a byte array.

The formatter is a BinaryMessageFormatter.

The destination queue is a private one, and I'm using direct TCP communication.

The destination machine is in a different LAN, I access it by its external IP address.

There's a firewall which routs the incoming TCP communication to the actual destination machine (port forwarding).

So the system's architecture looks like this:

[source machine] --> [destination firewall] --> [destination machine]

I've been using the system for a few months, and all went fine.

Recently we experienced a firewall failure.

Apparently, this caused to data corruption:

While the queue is transactional, and the message, according to MSMQ, was successfully delivered to the destination machine, the message's content was corrupted.

That is, the code for reading the message from the queue raised an exception:

try
{
    var message = queue.Receive(readTimeout, transaction);
    if (message != null)
    {
        data = (byte[]) message.Body; // this line raises an exception
        return true;
    }
}
catch (Exception e)
{
    Logger.Error("error reading queue", e);
}

I had to delete a few messages from (top of) the queue, and then the system got back to normal.

My question:

Assuming that it was only the firewall's failure that caused this, and knowing it's a transactional queue, how come the message was considered to be delivered?
Isn't MSMQ executing some kind of a checksum to ensure data integrity on transactional queues?

Answer 1

It currently looks like MSMQ entirely "trusts" the TCP layer when it comes to data integrity and completeness.

Answer 2

This is just a guess, but I think the Distributed Transaction Coordinator (DTC) might have troubles here. As the name implies, the DTC is responsible for handling the transactions that involve multiple system in a network.

What I could imagine in your scenario, is that the transactions cannot be correctly managed over your different LANs.

My suggestion to you is to check the configurations of the involved DTC instances in both networks if there are option to enable the communication between them and/ or research if the firewall needs to be set up for to allow DTC communication.