Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

This page contains a wish-list for version 1.1 of the Stomp protocol. Please feel free to add things you see missing in the current Stomp specification. This list will grow into a final 1.1 specification over time. For any discussion, please join some of our Mailing Lists

Message NAK

There's no explicit way to NAK a message (i.e. indicate that processing that message failed).

See http://old.nabble.com/un-ack-%28i.e.-indicate-message-failure%29--td16422072.html

Receive verb

"Store and forward" is a common use case for async messaging that's difficult to satisfy with the current protocol: collect messages in a queue, eventually a client connects, requests messages until the queue is empty, and then disconnects.

Adding a "receive" verb to the protocol would satisfy this requirement. It would use the same headers as the "subscribe" verb but would return immediately with either a message or an indication that there weren't any messages.

proposed by: toby at caboteria dot org

Wire format negotiation

We need wire format negotiations in order to make clients and brokers understand each other on what version of the protocol will be used. I think the best place to achieve this is during the connection procedure.

The client can include the version header into the CONNECT command frame, indicating the highest version of the protocol it supports. If there is no version header, version 1.0 is assumed (supports backward compatibility).

The server responds with CONNECTED frame and it can also include the version header, which also indicates the highest version of the protocol implemented. The lack of the version header assumes version 1.0.

Now since both the client and the server knows capabilities of each other, they can use the highest version they both support.

A few examples:

Code Block
CONNECT
login: <username>
passcode: <passcode>
version: 1.1

^@

CONNECTED
session: <session-id>
version: 1.1

^@

version 1.1 will be used.

Code Block
CONNECT
login: <username>
passcode:<passcode>
version: 1.1

^@

CONNECTED
session: <session-id>

^@

version 1.0 will be used.

JSON basic type notation for header values

Currently header values are interpreted as plain String, which makes usage of selectors with numerical values impossible with Stomp.
The idea is to support following notation for header values:

  • Number (integer, real, or floating point)
  • String (double-quoted Unicode with backslash escapement)
  • Boolean (true and false)
  • Array (an ordered sequence of values, comma-separated and enclosed in square brackets)
  • Object (collection of key/value pairs, comma-separated and enclosed in curly brackets)
  • null

Message transformation

We should include "message transformation" feature (implemented in ActiveMQ already, unfortunately not documented well), which allows you to do transformation of frame content to object, map or byte messages according to the transformation header provided. Currently, support for XML and JSON encoding
is supported with the following values (jms-byte, jms-object-xml, jms-object-json, jms-map-xml, jms-map-json) of the transformation header.

So for example, the following command

Code Block
SEND
destination:/queue/TEST.Q
transformation:jms-map-xml

<map>
  <entry>
    <string>name</string>
    <string>Dejan</string>
  </entry>
  <entry>
    <string>city</string>
    <string>Belgrade</string>
  </entry>
</map>

^@

would send a map message to the queue.

Message types

Allow a consumer to consume different types of messages. Message transformation allows consumer to subscribe with certain type of transformation, after which it will expect only one type of messages (text, object, map or byte). We should add one more optional header to MESSAGE command called message-type. This header can have the same values as transformation header used on SEND and SUBSCRIBE commands, jms-object-xml for example. This header value instructs the broker to do the appropriate transformation, even if it is not specified by transformation header. Also, the broker can automatically transform messages sent with "native" JMS clients and consumed by Stomp consumers. This header can also help Stomp consumers to determine the type of the message, if they are consuming from destinations that contains multiple-type messages.

Content encoding

(stomp 1.0 supports binary messages, that is the very reason there is a content-length header)

Support content-encoding header for SEND and SUBSCRIBE commands allowing to send gziped and base64 encoded content.

I would prefer to send and receive binary messages as base64 encoded text, since it seems more natural to me for this kind text-based protocol. Again, this introduces the concept of binary message to Stomp protocol, which I'm not sure we want to do. But surely, gziped content would be appreciated in many contexts.

Optional Keep Alive protocol.

Right now we have to depend on the OS
to detect socket failure to time out a dead client. Would be nice if
the client could optionally agree to send a Keep Alive commands when
the connection is idle. That way the sever can detect dead clients
quicker.

Virtual hosting

Perhaps standardize a 'host' header in the CONNECT frame to specify
the host name that the client is connecting to. This would allow
implementing virtual hosting where multiple DNS host entries point at
the same STOMP server.

Individual acks

(this comment must refer to an older version of the spec, since the v1.0 protocol does specify a required message-id header that indicates which message is being acked)

The Stomp specs at http://stomp.codehaus.org/Protocol does not detail the ack behavior nor does it recommend or hint anything.

Introduce a new ack mode in Stomp SUBSCRIBE header:

The chosen header is called 'client-individual'; to reflect that ACKs are still client initiated PLUS "individual" to
declare that the client intends to acknowledge individual messages by message-id, not in batches as with simple 'client' ack mode.

Kindly suggest a another header name if you can think of a more appropriate one.

PING

Ping just verifies that the server is alive. The server should respond with "Pong" to indicate that it is indeed there.