Brian's Waste of Time

Sat, 06 Aug 2005

Trivial Text Messaging Protocol (working name)

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://
session: 445a99490cdaed59122962bc1fd98051
reply-to: ttmp://

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!

5 writebacks [/src] permanent link