The first few sections of the network we have been through the basics of communication, today really began to show the operation. This section describes how to define the packet structure at the application layer. Good packet design facilitates service expansion in the future. We’ll talk a little bit about byte ordering.

You can see that the most recent chapters combine the two sections into one. The main reason here is that when drawing up the title of some chapters, I forgot to pay attention to the length. It is not appropriate to remove it alone. If there is such a need to merge it in the future, I will not do additional explanation. O o (studying studying)

chapter

  • Android communicating with iot Devices – A concept starter
  • Android communicating with iot devices – The essence of data transfer
  • Android and iot device communication – Network model layering
  • Android and Internet of Things device communication -UDP protocol principle
  • Communication between Android and iot devices -TCP protocol principle
  • Communication between Android and iot devices – based on TCP/IP custom messages
  • Android communicating with iot devices – What is byte order
  • Communication between Android and iot devices – byte packet assembly and parsing
  • Android communicates with iot devices – use UDP broadcast to do device lookup
  • Android and Internet of Things device communication – remote control Android client
  • Android communicates with iot devices -Android makes small servers
  • Android and Internet of Things device communication – debugging tips
  • Android communicates with iot devices – parallel serial and queue
  • Android communicating with iot devices – Data security
  • Android communicates with iot devices – heartbeat
  • Android and Internet of Things device communication – network IO model

directory

  • Custom message
  • Byte order

Custom message

What is a message?

In fact, in the previous chapters, we have analyzed each message in the network model. If nothing else, you already know them.

Figuratively, the message is like a storage box that can be seen everywhere in our life.

It’s used to hold things. (Duh!)

Storage boxes produced by different manufacturers have different sizes and container space. Although they are all called storage boxes (as are packets). But there are different things to store.

Also, it’s worth noting that a storage box often has separate areas for you to place items that fit in their card slots. This is also strikingly consistent with our message. If you shove in something that doesn’t belong in this place, you’ll break it. Placing content in the wrong field in a message can also cause disaster.

In a word, a message is a format description designed to store content for a specific business. It is with this format that the sent data can be referenced without being confused. Now that you have a good idea of what a message is, let’s define a set of messages.

define

How do I define that? Not out of thin air. We need business first.

Requirements:

We need to control the switch, mode and temperature of air conditioning through mobile phones. Please design what the mobile phone should say to the air conditioner and how the air conditioner can recognize the content sent by the mobile phone.

I won’t draw the logic diagram of the remote control because I’m lazy, so you can imagine.

What, you can’t fix it in your head?

You know, when you press the remote control on the air conditioner.

Field analysis:

The requirements here are broken down into three functions:

  • Switch: Belongs to true and false logic.

  • Mode: refrigeration, heating, automatic, ventilation, dehumidification, etc.

  • Temperature: a number.

Through the analysis of functions, it is shown here that the design field of this packet needs to meet three functions. And the content of each function is inconsistent. With true and false, enumerations, and values, the length of the corresponding content is also inconsistent.

Ok, I first give my design message structure scheme, let’s have a look.

Basic structure:

  • Length: Indicates the number of bytes after the length field.
  • Device number: indicates the serial number of the receiving party, which is used to confirm whether it is the packet it needs to be related to.
  • Function code:A description of what to do. Like this one right hereSwitch, mode, temperature
  • Content: The function code corresponds to the content to be transparently transmitted.
  • Checksum: Ensures data integrity and consistency.

This is very similar to the structure we introduced in the first section. Let’s move on to see how variable length is used in content.

The above table shows the structure and length of the corresponding content of the function code, with the simplest switch as the column. We send a packet. In Java, the data would be assembled as follows.

Represented as a Java object:

public class AirCondBaseStructure {
    int len; / / the length
    byte sn[]; / / serial number
    byte code; / / function code
    byte data[]; // Pass through data
    byte crc[]; / / check
}
Copy the code

All that’s left is to stuff the object with data according to the corresponding function. (The lower level is called a structure)

The resulting data looks something like this:

Switch message:

0x00 0x00 0x00 0x11 | 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 | 0x21 | 0x01  |0x57 0x9D 
Copy the code

We manually parse a handful of hexadecimal data according to the packet table above:

  • Length: 0x00 0x00 0x11int Type station four bytes, where 0x11in decimal form is 17.

  • Device number: 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 Contains 13 bytes and is translated into 1234567890123

  • Function code: 0x21 Directly corresponds to the switch function in the table.

  • Contents: 0x01 directly corresponds to the opening in the table.

  • Checksum: 0x57 0x9D Data is correct if the check is consistent with the sender.

Device number 13 bytes + function code 1 byte + content 1 byte + checksum 2 bytes The exact length is 17.

Similarly, if the function code here is replaced by temperature regulation, the length will change. Because the content structure of temperature is shot, it takes up two bytes. And so on, the rest of the messages are like cannons.

Here are the other two sets of messages, so you can try to interpret them yourself and see if you can read them?

Mode message:

0x00 0x00 0x00 0x11 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x22 0x01 0x57 0x6D 
Copy the code

Temperature regulation message:

0x00 0x00 0x00 0x12 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30 0x31 0x32 0x33 0x23 0x00 0x1A 0x0D 0x95
Copy the code

I’ll give you a homework assignment, and if you want to get the hang of it, you can try to write it yourself and assemble a message and convert it into bytes, and then convert it back to an object. I’ll release the parsing code for this section in the next section.

Byte order

It can also be read literally as byte order. Students who develop applications in the upper level may really have little access to them. Because you usually use big port notation. Java also defaults to big-endian notation. So much so that you’re even hearing about it for the first time?

Let’s look at what byte order is:

In the case of int, we know that an int takes up four bytes. How are four bytes arranged in byte form on a computer?

For example, int a= 201806; It’s going to look something like this

Little endian representation: 0x00 0x03 0x14 0x4E

Description Of big Endian port: 0x4E 0x14 0x03 0x00

They all represent the number 201806, the small port is the low byte before the high byte after. Big port is just the opposite is high in the front low after.

Ruan yifeng teacher from the blog to see a very image of the map. Let me paste:

Explain why there are two different byte orders. Because the computer doesn’t know what a single byte means, it just reads it stupidly. Computers are designed to be more efficient in the lower part, but people are more accustomed to the higher part. So there are two patterns.

In the development of the Internet of Things, some hardware embedded development will adopt the small end mode, while the upper application developers tend to use the big end mode. If one party does not deal with this transformation, it will cause the low-level error that the data always reads wrong and the code looks consistent with the protocol implementation.

Part reference: Understanding byte order