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, 10.0.0.254 is the client and 10.0.0.9 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:
END POINT MAPPER:
================
UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA
DTCPING:
========
UUID 75687379-AAAA-44F6-9512-080AC70F8AD9
WINRM:
=====
2b7ee790-e8c8-4820-97db-cdff70129887
DTC:
======
AFA8BD80-7D8A-11C9-BEF4-08002B102989
906B0CE0-C70B-1067-B317-00DD010662DA
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