OBEX and ISO8583

| 4 Comments

OBEX is a nice little protocol and reminds me a bit of a massively simplified version of ISO8583. It's a pity about the warts on Connect...

The OBEX spec defines objects (messages) in terms of a fixed opCode, followed by a 2 byte length indicator followed by optional headers (fields). Each header identifier indicates both the type of header and the way that the length of the header is encoded. Everything in a message is a header - there's a 'body' header for sending data...

So it's all quite easy to parse. You start at the front of your byte buffer, pull off the opCode, grab the 2 byte length and you know if you have the whole packet. Then you start chomping your way through the headers, reading the single header identifier which tells you a) the type of the next header and b) how to work out how big it is.

So a PUT might look like this: 0x02 0x04 0x22 [headers]

The 0x02 is the PUT opCode. The 0x04 0x22 is the length of the packet and from then on it's all headers...

Except Connect is different.

Connect looks like this: 0x80 0x00 0x07 0x10 0x00 0x20 0x00 [headers].

0x80 is the opCode, the packet is 7 bytes long and then...

We have 4 bytes of extra stuff, we'll call them warts, before the headers can start. The extra stuff is used to negotiate the connection, the first byte is the OBEX version number, the second is a 'must be zero' flag byte, the last two are a request for a max packet size. Why aren't these pieces of information just headers like everything else? Suddenly we've gone from a nice, uniform, easy to parse, no special case, protocol to a situation where 'if the first byte's 0x80 then'...

And this for a saving of, say, 2 bytes. If all of the connection info were stored in a single header then we'd have 1 additional byte for the header identifier and another byte for the length. I don't think it was worth the saving for the added code complexity.

I know it's not a great deal of added complexity, but it's enough and it's unnecessary. It looks like someone who wasn't in on the design of the spec from day one decided they needed some extra stuff in the connect packet and just shoved it in... Given that Connect is 'optional' and devices should work without having had a Connect sent it looks like the whole concept of the Connect packet was a late addition... This is how a design starts to decay.

A pity.

4 Comments

What is iso8583 and how can it be implemented

Hello,

I'm doing a research for my bachelor project about how to implement a parser/formatter that converts an ISO8583, NDC and XML IFX messages in a internal representation message (maybe a hashmap).

Basically what I need to do is: from a raw message, parse it and generate an internal message. The raw message can be from any interface (ISO8583, NDC or XML for now), so I need to detect it and parse it for generate a convenient internal message.

I hope anybody can help me about that, I'm new in the transaction field and need a guidance on how to proceed.

Thank you very much.

Search Google? A search for ISO8583 currently gives lots of results, including a wikipedia entry that probably gives you enough to start on the 'parse a message' bit...

How are you going to store the messages internally?

Leave a comment