Clarification about "when" RECEIPT frame will be sent to client

[mjustin]

Hello group,

imagine I wrote a minimal STOMP client implementation which handles
only this basic scenario:

* client opens a socket connection to server
* client starts sending messages, the SEND frames use a receipt header
* client receives RECEIPT frames

The specification (1.1) does not say if the server must send the
receipt before accepting the next message.
This in turn means that the client-server message flow could be

client
SEND message 1
SEND message 2
SEND message 3

and after a while
server
RECEIPT message1
RECEIPT message2
RECEIPT message3

which is kind of 'asynchronous' receipt

but it could also be like this, more a 'synchronous' receipt
processing

client
SEND message 1
server
RECEIPT message1
client
SEND message 2
server
RECEIPT message2
client
SEND message 3
server
RECEIPT message3

In other words, the client implementation must be prepared for both
styles (because the specification does not enforce one style or the
other).

Problem with the asynchronous style is that the implementation is more
complex - it has to keep all receipt id's of sent messages to match
them when the receipt frames come back.

[Hiram Chirino]

The intent of STOMP is to allow that asynchronous receipt flow. But
it's the client implementation which dictates how the message flows
will apear. If a client always wait for the receipt of a message
before sending the next message then it will end up having the
synchronous receipt message flow you described in your message.

Regards,
Hiram

FuseSource
Web: http://fusesource.com/