3 ms·

I work in telecom, and this makes me think of two protocols I work a lot with, SS7 and SIP. SIP is like HTTP, in fact I believe it was modelled after HTTP and

I work in telecom, and this makes me think of two protocols I work a lot with, SS7 and SIP. SIP is like HTTP, in fact I believe it was modelled after HTTP and has a lot in common with it. You can troubleshoot SIP issues very easily using a packet inspector like ngrep (using Telnet might be a bit difficult as there are some timers that expire if you don't respond fast enough, but that's besides the point). Then there's a protocol like SS7 which is binary based. It's all structure binary bit fields. Even though it's binary based, and not very human readable, we have tools that decode the bits into a human readable format, which in turn makes it just as easy as SIP to troubleshoot. The question I ask myself is, which one would be easier to implement, text based or binary format? I guess I'd lean towards text based--in fact I have implemented a SIP client myself with success. But have yet to implement any kind of SS7 or binary based protocols. Perhaps experience has something to do with it, would having experience implementing binary protocols make it any bit easier? And to be fair, SIP is also much well more documented then SS7. As well it's easier to test SIP. I'm just starting to work with binary protocols, so it will be interesting how much progress I make. I realize there are also some libraries that help with working with binary/bit field data.

toast0 13y ago
binary protocols can be easier to develop, because generated and parsing the protocol stream is usually straight forward: if there's a variable length field, you will typically get the length first and then the field; no need to scan byte by byte for a terminator(s) or handle escaping of terminator(s). There's often less need to be liberal in what you accept too (but that may depend on how the protocol is versioned) But if you're developing for a protocol with garbage documentation (or no documentation), a text based protocol at least offers some amount of intrinsic documentation.

toast0 13y ago

binary protocols can be easier to develop, because generated and parsing the protocol stream is usually straight forward: if there's a variable length field, you will typically get the length first and then the field; no need to scan byte by byte for a terminator(s) or handle escaping of terminator(s). There's often less need to be liberal in what you accept too (but that may depend on how the protocol is versioned) But if you're developing for a protocol with garbage documentation (or no documentation), a text based protocol at least offers some amount of intrinsic documentation.