This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: Trivial Text Messaging Protocol (working name)
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
Chatted with James
and Max (no link for Max, don't really know him) about the trivial
MQ wire protocol/format I'd talked
about previously. We all rather agreed that it should be TCP
based, despite the ease of implementation in a REST-y manner. We
looked at BEEP, figuring we
are reinventing stuff here (which we are) and BEEP is nice, and is
optimizable, but it fails an important test, I cannot (easily) use
the protocol by hand via netcat.
Current thought for messages is borrowing a lot from HTTP and SMTP
-- they both work really well, after all =)
SEND ttmp://example.org/queue/EXAMPLE
session: 445a99490cdaed59122962bc1fd98051
reply-to: ttmp://example.org/session/445a99490cdaed59122962bc1fd98051
This is the message body^@
Should be pretty self explanatory. We dropped the xml encoding of
the message, line-oriented is equally (or more) clear, less verbose,
and less problematic for encoding XML as the message body.
Now, some stuff I haven't discussed, but have been thinking
about. This looks, smells, and even acts in many ways like SMTP. It
isn't. SMTP supports a lot of stuff I have no desire to
support. Also, TTMP (working name) requires a bunch of stuff you
could never retrofit onto SMTP now -- like requiring authentication,
period (the session is a key obtained from logging
in). I strongly suggest any implementation use SSL instead of raw
TCP in order to prevent replay attacks, but that is up to the
implementation).
"Automatic" reply-to has been dropped, a given connection will
always be given a receive-only queue it can listen on as part of the
login process, that is the recommended reply-to if you
need a private temporary queue. Implementations may delay actually
allocating any resources to said temporary queues until such a time
as a message is sent, so it is really just reserving a name.
The last interesting bit of the message format is the ^@ -- that is
a null, ASCII-0. It is a specific known terminator and the one
character disallowed in the message body. Yes, this will negatively
impact performance compared to a message body size in the headers,
but I cannot add up sizes when using netcat, so that option isn't
there.
Probably need to figure out the commands next, and maybe provide
some EBNF for them in order to start making it a properly formal
spec. Feedback much appreciated!
Previous Topic
