Version: 1
-Previous: f8920c914cf637eff84f71922146e8655ec4c00c
-Head: d74e4c3e9bee087fa3ea667d2dc623758e6f91d9
+Previous: b667d0528e81706882a7a243e5e8c497f89545dd
+Head: fedf3b46fd49cba77a604c03c0642224aedc5fa4
Applied:
rm-build: f8b9ec0b6d170b978c0e0167d76425f613b07971
umad: 26bd844e056198d42ea23289b7ee6cbf8258ff57
wv-pkey: 26a6f435fea9c4f89a45301b4197ff1282c7aa1e
iface: d74e4c3e9bee087fa3ea667d2dc623758e6f91d9
+ wv-dreq: fedf3b46fd49cba77a604c03c0642224aedc5fa4
Unapplied:
test-wv-print: e22c09acef52e5c119f80c0a646bcf9035094b80
test-pkey0: 812ba9c5ccb0e841f37bdc52713151bd4175613e
--- /dev/null
+Bottom: 15e8d01efddb1d7f4b1330b22f7cb9f0c6bcfe3a
+Top: 15e8d01efddb1d7f4b1330b22f7cb9f0c6bcfe3a
+Author: Sean Hefty <sean.hefty@intel.com>
+Date: 2010-01-18 22:02:49 -0800
+
+winverbs/ep: handle receiving REQ then DREQ
+
+For fast connections, it's possible to receive a DREQ immediately
+after receiving a REQ, without an RTU coming in between. If we've
+sent a REP to the REQ, then the DREQ should be treated as if the
+connection had been fully established. (The RTU could be delayed,
+and the communication established event is processed asynchronously,
+so there's no way to tell for certain.)
+
+This fixes an issue where the passive side Accept() call fails
+waiting for the RTU, but receives a DREQ instead.
+
+Signed-off-by: Sean Hefty <sean.hefty@intel.com>
+
+
+---
+
+