Hacker News Reader

Comment by pbsdp | Hacker News Reader

When its easier to write tools, tools are more plentiful. Same binary protocols make it an afternoon's work to implement most protocols, and even less time if all you want to do is open up a socket and send some EHLOs.

Text protocols, on the other hand, require writing a parser, dealing with encoding back and forth between string representations and binary data, handling line delimiters, etc.

I'll take binary protocols any day of the week. Any cost they incur in not being human readable is offset by the value of them being so easy to implement.

View on HN

It sounds like your argument is a preference for a pre-written parser library over having to write the parser yourself. Yeah, sure, no one would disagree with that for day to day use. It's when you don't have the pre-written library available that a text-only protocol will save your day.

Since binary protocols are easier to write tools for -- and difficult to us without them -- the tools get written.

Slowing down everyone forever just to ease telnet debugging is a misdirected optimization.

The tools might get written. But they won't be installed on those routers, remote servers you're not getting to install stuff on and all kinds of other places where people who work with networks frequently want to be able to talk protocols from.

It's largely irrelevant to me if there are tools out the wazoo to work with some binary protocol if I'm unable to run that tool everywhere.

And there's a huge range between advocating arbitrarily complex and flexible text protocols vs. binary protocols. You can "easily" do text protocols that are picky about field lengths and that use formats that can be parsed much faster than the more complex protocols.

If your protocol is using a small enough, regular enough grammar, it'd also be fairly trivial to allow a binary serialisation of requests or responses as an option without much extra overhead. E.g. start client connections with a word indicating it wants to "switch on" binary and length prefix any variable length fields instead of relying on an end of field marker, for example. (Or make human clients type out a word to switch to the text serialisation).

But very few protocols are so affected by latency in request/response exchanges that binary vs. text is a huge deal. For HTTP moving to a pure binary protocol might make sense because of how heavily we depend on it. But most protocols are not HTTP.

This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.

Do you have netcat compiled for Cisco IOS and JunOS? If so, please send them to me, and let me know how to get them into the devices firmware.

It might sound like scaremongering to you. To me, the reality is every network I've worked on have had devices that I can not install and run arbitrary code on. Most non roll-your-own routers for example does not give you a shell where you can install arbitrary applications. But many of them do have tools like ability to telnet to help diagnose problems.

So how do you debug the myriad of binary protocols that already exist today? How do you debug SSL services?

For that matter, how do you perform more than cursory debugging of HTTP services? Do you seriously sit there and carefully type out HTTP 1.1 compliant requests, along with requisite headers and maybe even cookies? Does that actually work for debugging complex issues, and does it really differ that substantially from the debugging one performs to see if a binary protocol service is up and accepting requests?

Reply on news.ycombinator.com