[Updated Design] ServerSuperIO 2.0, a cross-platform Iot communication framework, provides functions, bugs, details, and upgrades !, Serversuperiobug

[Updated Design] ServerSuperIO 2.0, a cross-platform Iot communication framework, provides functions, bugs, details, and upgrades !, Serversuperiobug
Note: ServerSuperIO 2.0 has not been submitted to the open-source community for internal testing !!!

1. ServerSuperIO (SSIO) Description

SSIO was developed and evolved based on the 300 baud rate communication and transmission application scenario in the early industrial field. To adapt to the development trends of the Internet and Internet of Things and the needs of different application scenarios, SSIO is constantly updated.

SSIO is a cross-platform Iot communication framework, but it is not only a communication framework, but a coordination and scheduling mechanism between device drivers, serial ports, network I/O managers, and scenario controllers.

Iot is a development trend. If protocol drivers of various sensors and hardware devices cannot be unified, use the SSIO framework to develop device drivers and mount them to the framework for communication and interaction, what you have is the integration capability and commitment to users. If the protocol is "standard" for internal use within the company, it is simpler and more convenient to use SSIO, reduce personnel costs and improve production efficiency.

2. Upgrade Overview

1.1 features

1. added the receiving data cache function in the serial port and network I/O to make full use of the cache space to ensure data integrity.

2. Modify the data distribution policy to distribute data by using remote IP addresses or device numbers.

3. Added receiving data filters to ensure data extraction according to certain rules and data continuity.

4. Add a timer and time-out to clean up network connection resources. If the network connection does not receive data within a certain period of time, clean up.

5. Other code optimizations.

BUG 1.2

1. Fix: Possible exceptions caused by software exit.

2. Fixed the logic issue of data distribution.

1.3 details

1. added the GetCode and GetPackageLength interfaces in IProtocolDriver. GetCode is generally the unique ID of the device. GetPackageLength generally obtains the length of the data to be received in this packet, which is not actually used in the framework.

2. Change the CommandCache Command Space to DataCache. The ISendCache sending cache interface and the IReceiveCache receiving cache interface are added below.
3. Change the CommandCache in the current device driver to SendCache to send the data cache and port it to the ProtocolDriver protocol driver.
4. added the receive ecache data cache in ComSession and TcpSocketSession.
5. added the IReceiveFilter receiving data filter interface.
7. Remove distributing data by device address and add distributing data by device code.
8. When the network listens for a connection, exiting the software may cause exceptions.
9. When the network receives data asynchronously, it may cause distribution errors logically.
10. modify the configuration file and add StartReceiveDataFliter, ClearSocketSession, ClearSocketSessionInterval, and ClearSocketSessionTimeOut.
11. Remove the number of times no data is received during network communication to clean up the connection.

 

3. Upgrade considerations

3.1 device/sensor code

The device address (DeviceAddress) is used to identify the device driver, and the DeviceAddress is int type, which cannot meet the needs of business scenarios, because the device encoding is not only a numerical value, it may be a string of numbers and letters. The device Code includes the device address, which is a rule code used to identify the device. Sometimes the device code is the same as the device address.

Therefore, the GetCode interface is added to the device driver. This interface is also used as an interface for querying devices using filters for Asynchronous Network receiving data. Generally, the StartReceiveDataFliter attribute of the configuration file device is required.

GetCode can perform fuzzy search and return the device code, as shown in the following code:

public override string GetCode(byte[] data){            int codeIndex = -1;            byte[] head=new byte[] {0x55,0xaa};            for (int i = 0; i < data.Length; i++)            {                if (data.Mark(0, data.Length, i, head))                {                    codeIndex = i;                    break;                }            }            if (codeIndex == -1)            {                return String.Empty;            }            else            {                return data[codeIndex + head.Length].ToString("00#");            }}

3.2 receive data cache

After receiving data before SSIO, the data is directly extracted from the cache and then returned to the device driver. Another solution is to create a larger cache object to store byte data, however, this solution wastes some memory space and efficiency.

SSIO now adopts a compromise solution. It uses the existing cache space (byte []) to manage and filter and extract received data in combination with the receiving data filter, it also provides persistent storage for unextracted data. The Code is as follows:

/// <Summary> /// obtain data /// </summary> /// <param name = "filter"> </param> public IList <byte []> get (IReceiveFilter filter) {if (filter = null) {throw new NullReferenceException ("filter reference is empty");} if (DataLength <= 0) {return new List <byte []> () ;}lock (_ SyncLock) {int lastByteOffset = InitOffset; IList <byte []> listBytes = filter. filter (ReceiveBuffer, InitOffset, DataLength, ref lastByteOffset); if (lis TBytes! = Null & listBytes. count> 0 & lastByteOffset> InitOffset) {CurrentOffset = lastByteOffset + 1; int gets = CurrentOffset-InitOffset; DataLength-= gets; MoveLeft (gets);} return listBytes ;}}

3.3 receive data filter

The receiving data filter searches for and extracts data information in the data cache according to certain principles. The filter interface defines the following code:

/// <Summary> /// filter data information /// </summary> /// <param name = "receiveBuffer"> buffer </param> /// <param name = "offset"> offset </param> /// <param name = "length"> valid data length </param> /// <param name = "lastByteOffset"> offset of the last byte </param> // <returns> no data returns null </returns> IList <byte []> Filter (byte [] receiveBuffer, int offset, int length, ref int lastByteOffset );

Based on this interface, SSIO Implements Five data filtering methods: FixedEndReceiveFliter, FixedHeadAndEndReceiveFliter, and FixedHeadAndEndReceiveFliter) fixedHeadAndLengthReceiveFliter and FixedLengthReceiveFliter have their own advantages and disadvantages. Use different filters based on the protocols of different devices.

3.4 timed detection, timed-out cleaning of Network Connections

In the past, SSIO used to set a sending and receiving number. If the number exceeds this value and no data information is received, it is deemed that the I/O channel is invalid and the resources are closed and released.

Now, the timing detection function is added for SSIO. If no data is received within a certain period of time (the device can), it is considered as an invalid IO channel, the resource is closed and released. The Code is as follows:

Private void ClearSocketSession (object state) {if (Monitor. tryEnter (state) {try {ICollection <IChannel> socketChannels = this. channelManager. getChannels (CommunicateType. NET); if (socketChannels = null | socketChannels. count <= 0) return; DateTime now = DateTime. now; IEnumerable <IChannel> timeoutSessions = socketChannels. where (c => (now-(ISocketSession) c ). lastActiveTime ). seconds> Config. clearSock EtSessionTimeOut); System. threading. tasks. parallel. forEach (timeoutSessions, c =>{ ISocketSession s = (ISocketSession) c); Logger. info (true, String. format ("network connection Timeout: {0}, Start Time: {1}, last activation time: {2 }! ", Now. subtract (s. lastActiveTime ). totalSeconds, s. startTime, s. lastActiveTime); RemoveTcpSocketSession (s) ;});} catch (Exception ex) {this. logger. error (true, ex. message);} finally {Monitor. exit (state );}}}

3.5 data distribution principles

There is no data distribution for polling mode communication, because each device driver at a height performs sending and receiving operations sequentially. the received data must be driven by this device and will be returned immediately.

However, for communication modes (application scenarios) in the concurrency mode, autonomous mode, and Singleton mode, How do I know which device driver should be allocated to the received data? There are two methods: By IP address and by device encoding (originally by digital device address ). The received data is compared with the device parameters through the device protocol driver and distributed. The following code:

/// <Summary> /// distribution data mode /// </summary> public enum DeliveryMode {[EnumDescription ("device IP distribution data")] DeviceIP, [EnumDescription ("device code distribution data")] DeviceCode}

 

1. [serialization] C # communication (Serial Port and network) Framework Design and Implementation

2. [Open Source] C # cross-platform Iot communication framework ServerSuperIO (SSIO) Introduction

2. Overall system construction solution using SuperIO and open-source cross-platform Iot framework ServerSuperIO

3. C # technical route of industrial IoT and integrated system solutions (data sources, data collection, data upload and receiving, ActiveMQ, Mongodb, WebApi, and mobile App)

5. ServerSuperIO Open Source Address: https://github.com/wxzz/ServerSuperIO

Internet of Things & integrated technology (. NET) QQ group: 54256083