Skip to end of metadata
Go to start of metadata

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:

version 1.1 will be used.

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

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.

  • No labels

1 Comment

    1. NAK: absolutely. It is a must.
    2. receive verb: I believe this is a bit more complex. How will the server know that the client does not want to get the messages automatically? The server will send the messages when they are to be processed by the client anyway without the verb 'receive'. What may be needed is to tell the server that the client is lazy and does not want to be flooded by messages and wants to get a message only whenever a 'receive' was sent through the wire. Client may tell its type to the server when it connects or it can switch between greedy mode and lazy mode.
    3. Wire format negotiation: version is only one thing. How about feature set negotiation? For example a server may support v1.1 but only in greedy mode and does not implement lazy mode (assumed that my idiot ideas go through). I suppose that v1.1 defines optional features and whenever a client needs that it says 'need: lazy-mode, binary-attribute' for example. Then the server may reply 'support: lazy-mode' noting in the example that 'binary-attribute' is not supported (whatever that is).
    4. JSON basic type notation for header values: Why JSON? There could be some more general method that could tell the other party that a header is of a certain content-type. I have no idea how. How about binary headers?
    5. Message transformation: I disagree to have a header named 'transformation' (and my objection is not the name). STOMP is a communication protocol that describes how to send a message over a byte stream. The message has to be clear but it is up to the receiver to decide what it does with it. STOMP is not a TCP level JMS specification. Instead my suggestion is to have a Content-Type header that may optionally define the mime type of the content.
    6. Message types: how about name it 'content-type' ?
    7. content encoding: Note that stomp 1.0 already support binary messages. If there is a need for content encoding then the information on the encoding should have a header and the header 'content-type' has to refer to the content after it was decoded and passed on to the consuming program. This however will drastically increase the complexity of a stomp client/server code and I believe if it gets into the v1.1 protocol it has to be an optional feature.
    8. Optional Keep Alive protocol: I agree. However if the client does not implement the keep-alive feature, it has to implement reconnecting therefore the server may decide to gracefully close the connection it does not get a pong for a ping.
    9. Virtual hosting: no. This is not a web server. There is a destination field already.
    10. individual ack: I do not get the point after reading 1.0 version spec. It does support individual ack.
    11. ping: Ping may be initiated by any side and the other party has to reply the pong.