Since they're something I'm often being asked about, and something not many people seem to understand, in this article I'm going to explain how binary messages work in Lacewing. (sorry about the weird formatting, something bad happened to the spaces when transferring it to the forum...)
[size:14pt]Why should I use binary messages?[/size]
I guess if you're reading this article, you're probably currently doing things the Moo way and sending delimited strings to be parsed on the receiving end with String Parser.
Let's imagine we have a networked application that has to send two numbers (perhaps X and Y coordinates?) - it sends them like this:
That string is 7 characters in length, which means Lacewing will use (excluding headers) seven bytes of bandwidth to transmit it. If we were using binary messages instead, this could be sent in only TWO bytes (or four if the numbers were larger than 255).
How? Well, each character in a string (letter, string, or number) is represented by an ASCII number (search for an "ASCII table" to see which numbers are used for different characters). The character that represents the number "1" is character number 49, the number "0" is character number 48. To send a string, Lacewing uses 1 byte (a byte can be any number from 0 to 255) per character. So the string above would be sent like this:
Which means the seven bytes:
are transmitted over the network. This is obviously a complete waste of bandwidth, because all we want to send is two numbers (104 and 178). Lacewing, thankfully, allows you to send the numbers directly, instead of sending a string, and that's what the binary message feature does.
That means you can send these bytes instead:
And read them on the other end. Considering how frequently you're likely to be sending messages, this can save a lot of bandwidth.
[size:14pt]How do I use binary messages?[/size]
I'll show an example of how to send the two numbers we were talking about above, and read them on the other end.
[size:11pt]Sending the binary message[/size]
Lacewing : Send text Str$(104) + "," + Str$(178) to channel on subchannel 0
Lacewing : Push byte 104
Lacewing : Push byte 178
Lacewing : Send binary to channel on subchannel 0
[size:11pt]Receiving the binary message[/size]
+ On text channel message on subchannel 0
- String Parser : Set source string to Received$("Lacewing")
- Active : Set X position to Val(listGetAt$("String Parser", 0))
- Active : Set Y position to Val(listGetAt$("String Parser", 1))
+ On binary channel master on subchannel 0
- Active : Set X position to Byte("Lacewing", 0)
- Active : Set Y position to Byte("Lacewing", 1)
And that's about it, as far as sending and receiving a message composed of bytes goes. Here's the catch: A byte can only hold a value from 0 to 255 (when you use the expression to read it as unsigned) or from -128 to 127 (when you use the expression to read it as signed). If you want values beyond this range, you'll have to use one of the other data types.
Lacewing allows you to write and read the following types from binary messages:
It's quite easy to understand how to use all of these types in your binary messages, providing you understand how Lacewing builds binary messages. When you add something to the binary to send:
You could now send the binary, and then on the receiving end, read the respective type at the respective index. So if you read an integer at 3, you'd get 31333337. If you read a byte at 7, you'd get 100. Basically, the position of everything in the binary starts at 0 (the first thing you add will always be at index 0) and from there, the index depends on how big the things you added afterwards were.
If we sent the binary above, containing the numbers 3, 572, 31333337 and 100, it would be 7 bytes in size. If you sent this as a delimited string "3,572,31333337,100", it would be 18 bytes total. This should give you an impression of how much space you can save using the binary messages with Lacewing.
I hope if binary messages previously made no sense to you, they make a little more now. Good luck