Analysis of Application Layer Communication Protocol development

original:http://blog.csdn.net/phunxm/article/details/5086080

1. The concept and elements of communication protocol

In the OSI Open Interconnect Reference Model, the data units between peer entities (peer) are encapsulated in the sender Layer (encapsulation), and the receiver is parsed (decapsulation) on a per-layer basis. The packets that the sender N-tier entity obtains from the N+1 layer entity are called Service data UNIT,SDU. N-tier entities only treat it as data that requires the service of the entity, encapsulate the service data unit into a data unit (Protocol data UNIT,PDU) that can be understood by the other, and the encapsulation process actually adds the peer-to-entity convention for SDU Control information (Protocol-INFORMATION,PCI) process.

To ensure the relative independence of each function of the network, as well as ease of implementation and maintenance, the protocol is usually divided into sub-protocols, and the protocols are maintained in a hierarchical structure, the set of sub-protocols is often referred to as the protocol cluster (Protocol Family).

The layering of network protocols facilitates the decomposition of complex problems into a number of simple problems, which divide and conquer . The protocols of each layer are implemented by the entities of each layer, and the entity that accomplishes the same protocol function in the peer layer of the communication parties is called the peer entity . Peer entities communicate by protocol, so the protocol reflects a horizontal relationship between peer entities of the peer layer, and strictly speaking, the protocol is a collection of rules and conventions that a peer entity adheres to together.

The communication protocol precisely defines the communication control information and the interpretation information of the two parties: the sender can encapsulate the specific information (text, picture, audio, video) according to the protocol exponentially the packet, and finally transmit on the network with the serialized bitstream When the receiver receives the packet, it resolves the bitstream to localized data according to the Protocol, thus obtaining the original information sent by the other party.

The communication protocol consists of three elements:

(1) grammar : Specifies the structure and format of information;

(2) semantics : The content that indicates the information to express;

(3) synchronization : The rules relate to the interaction and sequence of events between the two parties.

The realization of the whole computer network embodies the realization of the Protocol, the TCP/IP protocol is the core protocol of Internet.

2. Communication protocol Development Steps

(1) The development of the Protocol mainly includes protocol design, protocol form Description, protocol implementation and protocol conformance test. The development process of the Protocol is shown in step 1.

Figure 1 Protocol development process and steps

(2) The packet sending receive Model 2 is shown in the protocol design process.

Figure 2 Packet sending and receiving model in protocol design process

(3) Conformance testing of the Protocol

Protocol conformance testing refers to whether the test protocol can achieve the correct communication according to the expected control strategy, which is mainly embodied in the fact that after the packet is transmitted from the source to the signal house through the channel, the message House can parse the original information correctly according to the protocol.

The conformance test for protocol 3 shows.

Figure 3 Protocol Conformance test environment

According to the test environment can be divided into local testing and distributed testing, 4 shows.

Fig. 4 Local test method and distributed test method

3. Data packets and datagrams

To facilitate the description of custom protocols, or to borrow packets and datagrams to describe the encapsulated data units and transmit data units, the packets and datagrams here are completely different from the packet and datagram concepts in the TCP/IP architecture.

The packet described below refers to the basic unit of the package, which encapsulates the base message unit in the TLV(type-length-value) format, and the datagram package is the basic unit of the transmission with the header containing the serial number and command information. The receiving end parses the event type according to the command information, making a different resolution. a message entity is a linked list of multiple TLV packets .

4. Design of the packet TLV

From the application-level HTTP protocol, to Hypertext Markup Language HTML (Hypertext mark-up Language), to Extensible Markup Language XML (extensible Markup Language), they provide formatted storage of data, The specification of transmission and format display is the cornerstone of network communication. However, the essence of HTTP protocol and Html/xml is to define a bunch of tags (tag) to serialize the data, then the receiver can parse and restore the data according to the tag.

The key to a custom communication protocol is the rational Construction (construct) of the packet and the correct parsing (parse), which is the coding rules .

Abstract Syntax Tag ASN (abstract Syntax Notation) The length of the BER determines the encoding method, consisting of 3 parts identifier octets, length octets and contents octets, which is actually a TLV(Type-length-value) Model: The Type field (type or tag) is information about the label and encoding format, the length field defines the length of the value, and the Content field (value) represents the actual numeric value.

Therefore, a coded value is also called the TLV ternary group . The encoding can be basic or structural, and if it represents a simple type of complete explicit value, then the encoding is the basic type (primitive), and if the value it represents has a nested structure, then the encoding is a struct (constructed).

TLV encoding means encoding the type (TAG), length, and value to form a bit stream , decoding is the inverse of the encoding, and the original data is resolved from the bit stream buffer.

Design the TLV protocol class in the C + + programming language, as shown in Class View 5.

Figure 5 CTLV Class View

There are currently only two interfaces for setting the setvalue_int of the Shaping value (int) and for setting the string value (type c_string) setvalue_cstring.

The format in which TLV encapsulates data into packages is shown in table 1.

TLV Package
Head		Package entity
M_dwtag	M_nlen	M_pvalue

Table 1 TLV Package format

Description of the TLV interface:

(1) The value type label M_vttag is an internal auxiliary enumeration variable, which is determined according to the service type label M_dwtag that is passed when constructing the TLV.

(2) Tlv::m_nlen is determined when setting a specific value for the TLV.

(3) Package of TLV package:

• After creating a TLV object using the tag parameter, call the Tlv::setvalue_* method to populate the TLV with the specific values;
• Call the Tlv::tobuffer method to package to buffer streambuffer.

(4) TLV package parsing: After creating a TLV object, call the Tlv::frombuffer method to parse out the TLV from the buffer streambuffer.

(5) Encapsulation and parsing involves conversion of native byte order and network byte order.

(6) When the Tlv::setvalue_* method is called to populate the TLV, the number of uniform byte boundaries is 4.

5. Design of the datagram package

Unlike the underlying packet/datagram, which simply encapsulates the data hierarchy, the actual application is event-driven, so different signaling (event type tags) must be registered and then populated into the datagram. The receiving side makes corresponding event processing according to the signaling.

For example, in the C/s communication system, the client often has to log in first, through the server-side verification to carry out subsequent communication. Therefore, after the client runs, it is necessary to construct and send to the server a datagram containing the user name string strUserName and the password string strpassword that contains the login signaling; the server side parses the login signaling and then sends a checksum that contains the Login_ The receipt data for the response signaling and verification results is reported to the client.

The package class is designed in the C + + programming language, which is shown in Class View 6.

Figure 6 CPackage Class View

The package class formats the TLV into packages as shown in table 2.

Package Packages
Head			Serial number	Package entity
M_ncmdlen	M_dwcmdid	M_dwcmdstate	M_nseqno	Count*tlv

Table 2 package format

Description of the Package interface:

(1) The Package::m_ncmdlen is the length of the entire package, and the advantage of being the first field is that when a large packet is delivered, the receiver can control the read state based on the length of the data, thus receiving a large packet in batches.

(2) Package::m_ncmdlen is initialized to 16 in the constructor and grows when the PACKAGE::ADDTLV method is called to populate the package entity.

(3) Package Packages:

• After creating the package object, call the Package::setheader method to fill the head signaling;
• Create a TLV object and populate the data, then call the PACKAGE::ADDTLV method to populate the package entity;
• Call the Package::tobuffer method to pack the package into buffer streambuffer.

(4) Package Analysis:

• Create a Package object first, call the Package::frombuffer method to parse the package header and serial number from the buffer Streambuffer first, and then resolve the TLV from the remaining buffer and serialize it to the linked list.
• Call the PACKAGE::GETTLV method to find the specific TLV package from the linked list according to tag, and then call the Tlv::getvalue method to get the specific value.

(5) The Package::tobuffer method and the Package::frombuffer method mainly traverse the Package::m_tlv_list list, and then call the Tlv::tobuffer method and the TLV: The Frombuffer method resolves the TLV data unit.

Functional testing of TLV packets (mainly local testing)

Since the actual communication data is eventually converted to bitstream, only the variables that send the string type are tested, and only the protocol can be packaged and parsed correctly. Other types of normal data can be converted to string transmission, and finally, the receiver determines the value type M_vttag according to M_dwtag, resolves the specific value.

For testing the Tlv::setvalue_c_string method to populate the TLV, you need to consider the byte alignment problem. For C-state strings with a length of 4-byte multiples, the end of the '/0 ' end marker is omitted for packaging. You need to test a string that is not 4 times times the length and a string of 4 times times the length.

Locally tested, the Tlv::setvalue_int method and the Tlv::setvalue_c_string method are called to correctly encapsulate and parse correctly when constructing shaping and strings.

The function test of the package datagram is to combine the TLV into a packet and then add the signaling to complete the specific communication. The test of login login and sending message SUBMIT_SM indicates that the package protocol can be properly encapsulated and parsed correctly.

Using the package communication protocol in a real-world project, you need to control the read steps for a slightly larger chunk of data so that you can receive the complete packet of information.

Sample code download for this article: "TLV Application Layer Protocol Development Example"

Reference:

"Computer network protocol and implementation Technology" Lu Swen

"TLV format and codec example"

"XML and TLV package unpacking performance Comparison"

Analysis of Application Layer Communication Protocol development