What exactly does "messages will not necessarily be completed in order" mean?

fg1921

unread,

Jul 8, 2010, 6:31:35 AM7/8/10

to BLIP Protocol

Hi

Does the line in the specification "messages will not necessarily be
completed in order" mean that the actual client (not the BLIP
implementation) can receive message B before message A in:

- (BOOL) connection: (BLIPConnection*)connection receivedRequest:
(BLIPRequest*)request

Please elaborate.

Thanks

Jens Alfke

unread,

Jul 10, 2010, 2:41:42 AM7/10/10

to fg1921, BLIP Protocol

On Jul 8, 2010, at 3:31 AM, fg1921 wrote:

> Does the line in the specification "messages will not necessarily be
> completed in order" mean that the actual client (not the BLIP
> implementation) can receive message B before message A in:

Yes, although only in the case of long messages that get broken into chunks (4k by default) and interleaved during transmission. For example, if one peer sends a 16k message A and an 8k message B, the chunks will probably be sent in this order:
A1 B1 A2 B2 A3 A4
then the other peer will receive the complete B before the complete A, so the current implementation would deliver B to the delegate first.

—Jens

Guided Ways

unread,

Jul 10, 2010, 11:05:13 AM7/10/10

to Jens Alfke, BLIP Protocol

Hmmm. So the application might receive B (which was intended to arrive after A first). Doe the application then need to create an internal queue and manage delivery of messages itself? That sounds like a pretty complex thing to achieve and should really be hidden away by BLIP's implementation instead I would have thought. Any idea how the application could be relieved of the burden of managing the delivery order itself?

Thanks.

Fahad

Sent from my iPhone

Jens Alfke

unread,

Jul 11, 2010, 1:54:08 PM7/11/10

to Guided Ways, BLIP Protocol

On Jul 10, 2010, at 8:05 AM, Guided Ways wrote:

> Hmmm. So the application might receive B (which was intended to arrive after A first).

The current implementation doesn’t really have a notion of queueing messages one at a time. Instead, all messages that have been posted by the sender are available to be delivered. This works well when you have several different agents or subsystems on the two sides that want to communicate independently of each other, since none of them can block the others by sending huge messages, but not for a protocol that’s more linear.

The network protocol definitely supports this, it’s just something that would need to be added to the implementation and API

> Doe the application then need to create an internal queue and manage delivery of messages itself? That sounds like a pretty complex thing to achieve and should really be hidden away by BLIP's implementation instead I would have thought.

When receiving a message you can look at the message’s number. If you haven’t already received the message whose number is one less, push the message onto a queue. Otherwise, handle the message, then handle and remove the first message in the queue as long as its message number is one greater.

Another way would be to have the sender wait for a reply to its latest message before it sends the next one (but this decreases throughput.)

> Any idea how the application could be relieved of the burden of managing the delivery order itself?

Well, what you want is something like the ‘channel’ mechanism of BEEP (the protocol that inspired BLIP). Messages within the same channel are sent one at a time in order, though interleaved with messages from other channels. When I designed BLIP my goal was to make it a lot simpler; I knew channels were one of the more complicated parts of BEEP, and I didn’t need them for my own app.

Another way might be to add a notification when a message has been completely sent. Then the app could keep a queue of outgoing messages and not tell the BLIPConnection to send the next one until the previous one was finished. [I think the BLIPMessage.complete flag could be repurposed for this — currently it’s only used in incoming messages, to remember whether the complete message has arrived, but it could also be used in outgoing ones to tell when the complete message was sent.) The nice thing about this is that the queuing behavior could be implemented as an optional class, like BLIPRequestQueue, without complicating the existing code.

—Jens

Guided Ways

unread,

Jul 11, 2010, 6:18:26 PM7/11/10

to Jens Alfke, BLIP Protocol

Thanks a lot for your thoughts on this Jens. Yes I've been investigating similar ways of handling this as I didn't realise this was the case till I saw a couple of isolated cases where somehow a message was being delivered at the time the connection was being closed (believing that all messages have been delivered on order since the last one went out the window).