trevix wrote: ↑Fri Jun 08, 2018 10:10 am
Thankyou. As always you are very helpful.
(Livecode 8.1.10)
I just wish I could just code instead of constantly chasing LC bugs.
The most recent build will always contain the most complete set of fixes.
As for the added step of a length indicator:
This apparently complicates my protocol, having to write and read twice for each message.
A good scripting language like LC prevents us from having to think like computers. But when performance matters (and it doesn't always, but sometimes it does) thinking like the computer can help.
On the sending side, you could prepend four bytes for the length (if using binaryEncode, or padded with the same function to get 10-char output if you prefer), and write in one pass.
It's only the receiver that needs two reads.
But reading from an I/O buffer is not a big task; the stream is already open, the data already collected by the host OS ready to do your bidding. In some respects, a small read on a stream is more like parsing a variable than opening and reading a file, in terms of total system overhead.
But the benefits can be tremendous, depending on the payload size.
Lines, items, words, even characters -- all these things mean nothing to the computer. LC lets us conceptualize data that way, but at the cost of having the engine sift through bytes to understand the boundaries.
But bytes - now
there's something computers grasp easily. It's pretty much the only chunk type they understand.
When we read an I/O stream for a match against a string, every byte must be compared to the string in hopes of eventually finding that match. LC's pretty good about that so it's not like it takes that long, but consider what happens when we already know exactly how much to read:
Asking LC to read for a specified size allows it to pass that request almost directly to the I/O buffering in the OS, where the OS will then reach out and grab that
in one step. Byte operations are the only things computers can do, but they do them very well.
So while for us it means typing an extra line of code, for the computer it replaces potentially hundreds or thousands (depending on payload size) of strcmp operations with a gulp performed in a single step.
This is why HTTP 1.1 added the length indicator in the header. Speeds up and simplifies a great many things.
We can learn from that when crafting our own custom protocols as well.