Yes, should be a bit more clear. Need an independent way to verify that
data is matched
in the correct order sending this information as payload is one way to do
this. So,
sending unique data in every message, and making sure that it arrives in
the user buffers
in the expected order is a
The situation that needs to be triggered, just as George has mentions, is
where we have a lot of unexpected messages, to make sure that when one that
we can match against comes in, all the unexpected messages that can be
matched with pre-posted receives are matched. Since we attempt to match
only
Rich was referring to the fact that the reordering of fragments other
than the matching ones is irrelevant to the Gleb's change. In order to
trigger the changes we need to force a lot of small unexpected
messages over multiple networks. The testing environment should have
multiple similar
On Thu, Dec 13, 2007 at 10:49:45AM +0200, Pavel Shamis (Pasha) wrote:
>> Because we want to support mixed setups and create XRC between nodes that
>> support it and RC between all other nodes.
>>
> Ok, sounds reasonable for me. Just need make sure that the parameters name
> will be user
On Wed, Dec 12, 2007 at 03:10:10PM -0600, Brian W. Barrett wrote:
> On Wed, 12 Dec 2007, Gleb Natapov wrote:
>
> > On Wed, Dec 12, 2007 at 03:46:10PM -0500, Richard Graham wrote:
> >> This is better than nothing, but really not very helpful for looking at the
> >> specific issues that can arise
