3 ms·
Why not? It's a straightforward format that's widely adopted with easy-to-use libraries, and the data's tagged (with keys) so you get a bit of extra informatio
by verandaguy 9y ago
Why not?
It's a straightforward format that's widely adopted with easy-to-use libraries, and the data's tagged (with keys) so you get a bit of extra information when you're debugging.
It's a decent choice when you're building either a prototype, or not building something that's supposed to be extremely performance-oriented, in which case, I totally agree, a binary protocol would be more appropriate.
- userbinator 9y agoEvery layer of abstraction introduces additional complexity, and more significantly, possible error cases. Observe how the given code has a path to handle JSON encoding/decoding errors. If you use a plain binary protocol, that's not even a consideration. I know it may be a contrived example, but what happens if you try to send it several MB of JSON, well-formed or otherwise? Examining the code more closely, I notice that it only reads up to 4K at a time, and there is no message framing, despite using stream-oriented TCP. It's going to get very confused if it gets more or less than one exact JSON "message" per socket read. If you modify it so it does do framing, then the question above still holds... what happens if it runs out of memory, etc...? All questions which are completely avoided by a simple "read 4 numbers from the socket and set positions" protocol. Code in which error cases simply cannot occur, has no need to be afraid of even a fuzzer feeding it input. KISS, YAGNI. (The larger point I'm making is that simplicity is often surprisingly easy to apply, yet rather undervalued in these times of preferring more abstraction. Of all the easily-exploited IoT out there, I bet the majority of them would not be so if some simplicity had been applied to their design.)