7 ms·
Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement. Text protocols have difficult problems l
by lmilcin 5y ago
Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement.
Text protocols have difficult problems like escaping or detecting the end of particular field that are frequent source of mistakes.
The issue is that many (especially scripting) languages treat binary data as second class.
The only real issue is that inspecting the binary message visually is little bit more difficult. You can usually easily tell if your data structure is broken if it is in text form. What I do is I usually have some simple converter that converts the binary message to text form and this helps me inspect the message easily.
- chrismorgan 5y agoAnd capitalisation issues, and encodings… give me a binary protocol to parse any time. They’re normally comparatively well-defined, whereas text protocols are seldom properly defined and so have undefined behaviour left, right and centre, which inevitably leads to security bugs—or even if they are well-defined, they’re probably done in a way that makes your language’s string type unsuitable, and makes parsing more complicated.
- touisteur 5y agoJust use recordflux for binary parser proved absent of runtime errors... ;-)
- einpoklum 5y agoCan you expand on that a little?
- michaelmior 5y agoRecordFlux[0] is a DSL written in Ada for specifying messages in a binary protocol. Code for parsing these messages is then generated automatically with a number of useful properties automatically proven including that no runtime errors will occur. [0] https://github.com/Componolit/RecordFlux https://github.com/Componolit/RecordFlux
- pjc50 5y agoPeople say this, but then there's ASN.1 which has had critical security bugs in: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=asn.1 https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=asn.1 I will agree that exhaustively defining text protocols is extremely hard, starting from character set / encoding and getting worse from there.
- lmilcin 5y agoASN.1 is not a binary protocol. It is a language to describe messages. Typically you create message description which is then compiled to code that can serialize/deserialize messages in BER-TLV or PER-TLV. I know because I wrote a complete parser/serializer for BER-TLV. It is simple protocol and any security issue is in the parser/serializer and not the protocol itself. That for simple reason that the protocol is nothing more than a format to serialize/deserialize the data.
- lmz 5y agoTrue, but they certainly don't make it too easy either with the indefinite length constructs.
- admax88q 5y agoI guess if you're going to pick the absolute worst example of a binary protocol.
- lmilcin 5y agoThat is absolutely not fair. BER-TLV is really nice protocol. I have worked with it for couple of years when I worked on an EMV application. It uses BER-TLV to communicate with the credit card but it is also very convenient format for all sorts of other uses and I would use it wherever I could. Think of it as Json but in binary form. It is not complicated and I would not even bother parsing the messages -- I could interpret hex dumps of them by sight very easily.
- scruple 5y ago> give me a binary protocol to parse any time I don't disagree in principle but I've come across a handful of very poorly documentated binary protocols in my years and that is an extremely painful thing to deal with compared to text-based protocols.
- chrismorgan 5y agoUgh, flashbacks. Now that you’ve mentioned that I feel the burning need to change my wording to add the condition “fairly described”. I have also come across very poorly documented binary protocols!
- jrockway 5y agoI think it's pretty easy to make poor use of HTTP to the same end. Imagine you're dumping traffic between a client and a server and the exchange is: GET /asdfasdfasdfdsaf X-Asdf-Asdf: 83e7234 HTTP/1.0 202 X-83e7233: 1 X-83f730b: 4 It's text, but you still have no idea what's going on. Overall, I think it's kind of a wash. It's basically equally easy to take a documented text or binary protocol and write a working parser. Neither format solves any intrinsic problems -- malicious input has to be accounted for, you have to write fuzz tests, you have to deal with broken producers. It's a wash. People like text because they can type it into telnet and see something work, which is kind of cool, but probably not a productive use of time. I can type HTTP messages, but use curl anyway. (SMTP was always my favorite. "HELO there / MAIL FROM foo / RCPT TO bar / email body / ." Felt like a real conversation going on. Still not sure how to send an email that consists of a single dot on its own line though.)
- taejo 5y ago> Still not sure how to send an email that consists of a single dot on its own line though. A line starting with a period is escaped by adding an extra period; the receiving side removes the first character of a line if it is a period.
- knome 5y ago>Still not sure how to send an email that consists of a single dot on its own line though. It seems you prefix any line of data starting with a period with an additional period, to therefore distinguish it from the end of mail period. https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2 https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.2
- the_arun 5y ago>>* The author disclaims copyright to this source code. In place of >>* a legal notice, here is a blessing: >>* >>* May you do good and not evil. >>* May you find forgiveness for yourself and forgive others. >>* May you share freely, never taking more than you give. Above all, this note at the beginning of the source code impressed me.
- mucholove 5y agoI did implement a webserver (that supports websocket-a binary protocol) and also implemented a `make_binary_string` function along the wah so as to not lose my bearings. Printf is 100% amazing and I generally leave my printf statements inside all my code because I can switch them on and off very easily for any individual function by using macros. Also clutch :)
- daitangio 5y agoYes and no. Debugging a binary protocol is a bit more difficult then a text one; which is the reason HTTP is ascii based.
- zaarn 5y agoThe reason HTTP is ASCII based isn't because it's easier to debug. It's because back then the other end was as likely to be a human as a piece of software. Because HTTP in it's early days barely had headers or even formatting, so people typed "GET /" at the server directly or used the same method to send mail directly. Nobody does that anymore and debugging is easily solved by converting your binary protocol to a textual form.
- throw0101a 5y agoI question the ascertain that humans were doing "GET /" or "HELO my.fq.dn" on any regular basis. There were mail clients from the very beginning for example: * https://en.wikipedia.org/wiki/History_of_email https://en.wikipedia.org/wiki/History_of_email Perusing document-based information was also done via clients, first with Gopher and then with the WWW: either GUIs like Mosaic, or on the CLI via (e.g.) Lynx.
- zaarn 5y agoI would question if this weren't the case often enough that people would demand it be compatible with their teleprompter.
- michaelmior 5y agoI definitely did back in the day :) But I'm only one single human.
- lmilcin 5y agoI did both send mails over SMTP as well as downloading files from FTP using Telnet.
- jchw 5y agoThey definitely don't have to be. I've echoed these sentiments before. However, HTTP/2 and HTTP/3 certainly are, though the reasons why they are complicated have nothing to do with choosing to use a binary based format. (They are complicated for good reason, though, and I hope that browsers and servers can continue to support HTTP/1 as the baseline till the sun burns out, just to make life easier.)
- arcticbull 5y agoYeah, humans can roughly speaking infer the schema of a text-based protocol but require one for a binary protocol.