We will terminate our transaction as soon as we receive the first CM REP, since that provides all the state that we need. However, the peer may resend the REP if it didn't see our RTU, and if we don't respond with another RTU we risk being disconnected. (This protocol appears not to handle retries gracefully.) Fix by adding a management agent that will listen for these duplicate REPs and send back an RTU.tags/v0.9.8
|
|
||
46 |
|
46 |
|
47 |
|
47 |
|
48 |
|
48 |
|
|
49 |
|
|
|
50 |
|
|
|
51 |
|
|
49 |
|
52 |
|
50 |
|
53 |
|
51 |
|
54 |
|
|
|
||
36 |
|
36 |
|
37 |
|
37 |
|
38 |
|
38 |
|
|
39 |
|
|
|
40 |
|
|
|
41 |
|
|
39 |
|
42 |
|
40 |
|
43 |
|
41 |
|
44 |
|
|
|
||
71 |
|
74 |
|
72 |
|
75 |
|
73 |
|
76 |
|
|
77 |
|
|
|
78 |
|
|
|
79 |
|
|
|
80 |
|
|
|
81 |
|
|
|
82 |
|
|
|
83 |
|
|
|
84 |
|
|
|
85 |
|
|
|
86 |
|
|
|
87 |
|
|
|
88 |
|
|
|
89 |
|
|
|
90 |
|
|
|
91 |
|
|
|
92 |
|
|
|
93 |
|
|
|
94 |
|
|
|
95 |
|
|
|
96 |
|
|
|
97 |
|
|
|
98 |
|
|
|
99 |
|
|
|
100 |
|
|
|
101 |
|
|
|
102 |
|
|
|
103 |
|
|
|
104 |
|
|
|
105 |
|
|
|
106 |
|
|
|
107 |
|
|
|
108 |
|
|
|
109 |
|
|
|
110 |
|
|
|
111 |
|
|
|
112 |
|
|
|
113 |
|
|
|
114 |
|
|
|
115 |
|
|
|
116 |
|
|
|
117 |
|
|
|
118 |
|
|
|
119 |
|
|
|
120 |
|
|
|
121 |
|
|
|
122 |
|
|
|
123 |
|
|
|
124 |
|
|
74 |
|
125 |
|
75 |
|
126 |
|
76 |
|
127 |
|
|
|
||
296 |
|
347 |
|
297 |
|
348 |
|
298 |
|
349 |
|
|
350 |
|
|
|
351 |
|
|
|
352 |
|
|
299 |
|
353 |
|
300 |
|
354 |
|
301 |
|
355 |
|
|
|
||
324 |
|
378 |
|
325 |
|
379 |
|
326 |
|
380 |
|
|
381 |
|
|
327 |
|
382 |
|
328 |
|
383 |
|
329 |
|
384 |
|