Frame Ordering

Lionel Cons

unread,

Jun 21, 2010, 11:01:39 AM6/21/10

to stomp...@googlegroups.com

There is an other part of the 1.0 spec which is not very well
specified: the order in which frames are expected.

Example 1:
- client subscribes with ack:client
- broker has two messages to send to client
- broker sends message 1
- will broker wait for the ACK frame before sending message 2?

Example 2:
- client sends message 1 with receipt 1
- client sends message 2 with receipt 2
- is broker allowed to deliver receipt 2 before receipt 1?

There are probably other similar gray areas...

Cheers,

Lionel

Hiram Chirino

unread,

Jun 22, 2010, 6:50:51 AM6/22/10

to stomp...@googlegroups.com

On Mon, Jun 21, 2010 at 11:01 AM, Lionel Cons <lione...@cern.ch> wrote:
> There is an other part of the 1.0 spec which is not very well
> specified: the order in which frames are expected.
>
> Example 1:
> - client subscribes with ack:client
> - broker has two messages to send to client
> - broker sends message 1
> - will broker wait for the ACK frame before sending message 2?
>

Example 1 brings up the question of should Stomp connections have an
additional flow control model over what TCP provides. In general I
would say that the broker should not wait. It should send as many
messages to the client as the TCP flow control permits. This is the
simplest view of flow control.

But there are uses to restricting that down. I would say we need to
standardize a header to allow configuring a message based credit
window or prefetch. For example:

SUBSCRIBE
destination: foo
credit: 1

Every message sent to the client would consume 1 credit from the
credit window. A client ack would add credit to the window. When the
credit window is 0, the server should not transmit messages to the
client. Would a client need to be able to issue credits without
acking?

> Example 2:
> - client sends message 1 with receipt 1
> - client sends message 2 with receipt 2
> - is broker allowed to deliver receipt 2 before receipt 1?
>

I would say yes, the broker is allowed to do deliver receipts out of
order. The fact is that message1 could end up blocking on some
internal broker queue while message2 gets delivered and can be acked
faster than message 1.

> There are probably other similar gray areas...
>
> Cheers,
>
> Lionel
>

--
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://fusesource.com/

Ian Eccles

unread,

Jun 22, 2010, 8:15:02 AM6/22/10

to stomp-spec

+1 on both counts. Providing credit windows for ACK seems like a
nifty option to have. And I definitely agree receipts should be able
to be delivered out of order.

On Jun 22, 6:50 am, Hiram Chirino <hi...@hiramchirino.com> wrote: