Understanding MSDTC communication from network layer traffic


MSDTC relies on RPC to communicate from peer to peer. In general situations, it is supposed to be transparent for most users. However, when we are facing network or communication issues between two transaction nodes, understanding how the MSDTC works on RPC layer from network traffic will become quite useful for us to quick narrow down and understand the failure point.


Here I’d like to explain the MSDTC communication flow as below:


In this sample, is the client and is the server.


Stage I: TCP 3 handshakes and RPC binding to End Point Mapping:


Client -------3 way handshake --->135 Server

Client -------RPC Bind to EPM---->Server
Client <---------Bind Ack-------- Server

Client -------EPM Req------------>Server
Client <------Resp--------------- Server





Stage II: TCP 3 handshakes, RPC binding to dynamic port, and RPC messages request/response. At this stage, the proxy, the TM core, the XATM -- all of these are components that communicate with each other using this way for administration, transaction propagation, commit, and everything else.


Client -------3 way handshake------>Server
Client --------RPC Bind ----------->Server
Client<--------bind ack------------------Server

Client --------RPC request/resp OPnum=1/7-------> Server
Client --------RPC request/resp OPnum=2-------> Server

Client --------RPC request/resp OPnum=3-------> Server




Stage III: Server may tear down context after everything is done.


Client <-----Req opnum=4-------Server


From the above traffic sequence, we can see there are different OPnum numbers, They have special meanings during the DTC connection lifetime. Here is the list:


BuildContext                 1
NegotiateResources    2
SendReceive OpNum  3
TearDownContext       4
BeginTearDown           5
PokeW OpNum            6
BuildContextW OpNum 7


The UUID displayed in the trace also have certain meanings, here is some common UUIDs for MSDTC and test tools:




UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA




UUID 75687379-AAAA-44F6-9512-080AC70F8AD9











If we are using Microsoft Network Monitor 3.3, and reload full windows parser (In Network Monitor, click Tools -> Options -> parser, save and reload)




The MSDTC trace can become clearer (it auto parsed Optnums, below sample is for Stage II):




Best Regards,

Freist Li





Comments (0)

Skip to main content