Clarification on queued receives

[MaxF12]

It should be made more clear in what order queued receives are considered, i.e. what happens if an application calls Receive(minIncompleteLength=20), then calls Receive(minIncompleteLength=1). What now happens if e.g. 10 bytes of data arrive? Will the second receive only be considered after the first has been fulfilled?

[mwelzl]

It would seem natural to me that enqueuing is what it is - i.e., saying once "I can receive blocks of at least 20 bytes" cannot be undone.

So, if the sequence is:

1. Receive(minIncompleteLength=20)
2. Receive(minIncompleteLength=1)
3. 10 bytes arrive

... then the first Receive call should be the one that matters, and the 10 bytes would have to wait until another 10 bytes arrive before the second Receive call can be processed.

I think that @tfpauly should add a clarifying sentence because his implementation probably already does it in one way or another.

[MaxF12]

Perhaps its not such a big issue, but I think this would take the option away from application developers to have an OR option for receives. For example, an application would have no way to say that it wants to receive either something with minIncompleteLength 100 or MaxLength 10.

I also think there might be some confusion when it comes to requiring message ordering. For example:

1. Application calls Receive(maxLength=10)
2. Application calls Receive(maxLength=20)
3. Message with length 20 arrives
4. Message with length 10 arrives
5. Application get received callback for message with length 10
6. Application get received callback for message with length 20

For the application it now seems that the message with length 10 arrived before the one with length 20 even though that is not the case.