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


 



 dtc1.gif


 


 


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


 



 dtc2.gif


 


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)


 


 dtc3.gif


 


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


 


dtc4.gif 



 


Best Regards,



Freist Li


 


 


 


 

Comments (0)

Skip to main content