4 ms·

You've never needed a basic TCP test without installing wget/nmap/etc? Most operating systems and hardware devices have telnet available for this kind of low-le

by ddunkin 13y ago

You've never needed a basic TCP test without installing wget/nmap/etc? Most operating systems and hardware devices have telnet available for this kind of low-level troubleshooting. You've never needed to test an SMTP connection to see what the rejection message was on the remote server (when a user can't get you the bounced message you require)? You never wanted to see if an SSH port was open and what version was running? Telnet is available in every router and firewall I have, I can't install curl onto a router to generate a request from a remote network, and I'll never see wget there either. I do this stuff every day as part of my job, telnet is the go-to, the other utilities are fine, but they usually mask what I'm really looking for anyway, if they are even available on the platform I am using in the first place.

pbsdp 13y ago
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.
- DougWebb 13y ago
  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.
  - pbsdp 13y ago
    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.
    - vidarh 13y ago
      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.
      - pbsdp 13y ago
        This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.
        vidarh 13y ago
        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.
        pbsdp 13y ago
        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?

by ddunkin 13y ago

pbsdp 13y ago

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.

DougWebb 13y ago
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.
- pbsdp 13y ago
  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.
  - vidarh 13y ago
    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.
    - pbsdp 13y ago
      This is just scaremongering. Installing the command line LDAP tools (which is a horrendous binary protocol) is no harder than installing netcat or tcpdunp.
      - vidarh 13y ago
        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.
        pbsdp 13y ago
        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?