
STOMP – The Simple Text Oriented Messaging Protocol - newtfish
http://stomp.github.io
======
viraptor
I'm a bit confused why people want things like this. I mean, a simple protocol
is great. But why text? Text protocol for arbitrary data is always going to
make things more complicated than necessary. And even "text" STOMP includes
"NULL / octet 0" in the description.

Here are some thing that are complicated in text: escaping data, escaping line
endings, type of line endings, escaping headers, encoding and string
comparison, data delimitation, preallocating right buffer sizes, parsing long
values, parsing numeric values, potential for confusion on what's opaque and
what's parsable.

All of these are solved by even the most trivial binary TLV:

    
    
        4-byte tag, 4-byte length, lenth-bytes data
    

It's not going to be telnet-compatible, but it prevents so many issues from
ever arising. If you need to debug it, it's trivial to even look at the hex
dump of packets.

/rant (I don't understand the obsession with text formats)

~~~
brianm
I'm the author of original Stomp protocol. Much of what changed in 1.1 and 1.2
came from people smarter than me, so blame me for the ugly and them for the
good.

Why text? Because I wanted to be able to debug it with netcat, implement
minimal but acceptable clients by inspection of the wire, etc. More
importantly, I wanted anyone else to be able to do the same.

At the time, AMQP was just starting to get steam, and it was a gross,
exceptionally difficult to implement, binary protocol. (AMQP has evolved a
huge amount from those early forms.) In looking for something better, the ease
of using SMTP and HTTP and the fact that I often _did_ do them directly in
netcat to debug or understand behavior, decided the direction.

Sure, SMTP, HTTP, etc., style protocols can be wonky at times, but the number
of times I have in fact done them by hand is very high. Avoiding the need to
break out Wireshark, and write a message packer on the fly as Wireshark only
supports reading what comes across, makes using it, when you don't have a
client yet, great. I've had people implement clients, from learning about the
protocol to using the working client, _during_ a half hour talk about Stomp.
They can do this because it bootstraps on knowledge of HTTP, and text is easy
on humans (if more involved for computers).

This ease of examination and manipulation is the same reason that JSON is
(approximately) infinitely more prevalent than protobuf, thrift, avro,
messagepack, or even smile (which is the exact json semantics, but way more
compact and fast to parse). The desperate perl hacker of XML fame is a very
real thing, don't ignore the implementation and debug affordances provided by
text-based protocols.

~~~
_wmd
Hey Brian,

Just wanted to say thanks for Stomp, protocols that are simple enough to be
easily reimplemented are definitely underrated.

The Python story for Stomp is not so great, especially working with Twisted
(e.g. there I think stompest is the best option available). On profiling I
discovered this module's parser was horrendous, contributing something like
30% to my runtime.

Had it been some binary protocol with a complex spec, I might have spent days
reimplementing it, but producing a simple and fast parser took only an hour or
two, and now my problem is solved.

For others complaining about Stomp, my reimplementation is 116 lines of
perfectly testable code, and for a problem domain as simple as wrapping
messages up in a few verbs, this is how it should be.

(Will be releasing tinystomp.py at some point, but it needs a little tidying
up and documenting first!)

------
IgorPartola
When it says that it is difficult to implement the server correctly, I think
it's an immediate red flag. We went through this with HTTP (nginx retrying
non-idempotent requests anyone), and SMTP. I think the lesson learned that any
future protocols should require really good specs and every implementation
should follow them.

~~~
vidarh
It's not saying it is difficult to implement the server correctly. It is
saying "the server side may be hard to implement well". There's a subtle
difference there. The reason is not protocol complexity or a poor spec. The
protocol is simple and well documented. Rather it is an admission that
implementing a queueing server can be hard, depending on the semantics you
choose to implement, and certainly is harder than the client code.

The protocol is perhaps not the most efficient. It's primary benefit is the
simplicity and level of support in various environments. Having Stomp support
for a message broker is a great way of adding low-effort interoperability.

A Stomp based message broker was my first serious Ruby project a decade or so
ago, and getting the server "right" for our use case took ~500 lines of code
(using sqlite for queues marked persistent), which is incidentally about the
same size as the spec.

------
alphapapa
The web site seems to lack a description of STOMP's purpose, or examples of
how it would be used.

~~~
jasonkostempski
The "1.2" in the nav bar is a separte link, I missed it at first too:
[http://stomp.github.io/stomp-
specification-1.2.html](http://stomp.github.io/stomp-specification-1.2.html)

------
KaiserPro
I don't understand why you'd want to replicate HTTP style interactions for
this kind of job.

The headers are massive, take up most of the message and are overly verbose.

I know people fear binary protocols, but they really aren't something to worry
about if you make the correct tools (after all, text is binary, its just there
are a great many tools to read it.)

If you are serious and actually want to test your protocol/code, then you need
to implement a parser that's useable. (either in wireshark or pipeable from
netcat) You've done most of the work making the parse for the actual protocol,
going the extra mile and wrapping it so it can take STDIN shouldn't be a
terrible drag

~~~
_wmd
Parsing a few bytes of extra text pales in comparison to sending anything
across the network. For example in the time it takes to call an uncontended
futex() on Intel Xeon, libxml2 can parse about a kilobyte of XML

------
takno
I thought maybe there was a new version or something. How has the spec for a
perfectly common technology which has been stable for several years got this
many upvotes?

------
jnordwick
Why wouldn't you try to make this as easy to parse as possible, just as
prepend a size to the message at least, and possible to other fields
internally too. Make the size a fixed width and it makes reading easier.

I deal with crappy protocols on a daily basis in the form of FIX and other
exchanges. I hope to never have to deal with this one.

------
chvid
I am the only one who is confused with this protocol: what problem does it
solve and exactly what does it do?

------
em3rgent0rdr
2012 is latest release. Need to put (2012) in title, I think.

~~~
xaduha
It's a spec. The fact that it doesn't change every month is a plus. It doesn't
mean that a site or implementations weren't updated since 2012.

