We have already learned some basic properties and related methods of supersocket. Now we will focus on communication protocol. TCP and UDP are the first protocols that come to mind before reading official documents. TCP and UDP are transport layer protocols. Only the transport layer protocol defined in the Socket program does not allow the two ends of the network to communicate. We need to define application layer communication protocols to translate the binary data we receive into requests that the program can understand.

Command line protocol is a widely used protocol. Mature protocols such as Telnet, SMTP, POP3, and FTP are based on command line protocols. In SuperSocket, if we do not have a custom protocol, SuperSocket default protocol is the command line protocol, which greatly simplifies the development based on such a protocol. The command line protocol defines that each request must end with a carriage return newline “\r\n”.

SuperSocket designs two RequestInfo classes :StringRequestInfo and BinaryRequestInfo.

If we use the command line protocol in the SuperSocket, all received data will be translated into a StringRequestInfo instance.

Let’s look at the StringRequestInfo definition:

public class StringRequestInfo {

     public string Key { get; }

     public string Body { get; }

     public string[] Parameters { get; }

/* Other properties and methods */

                                       }

StringRequestInfo has three attributes. Key is the name of the Command line and is the string used to associate the Command. Data is the parameter part of a command; Parameters is a list of the Parameters of a command.

Because CommandLineProtocol default CommandParser uses Spaces to distinguish command names from parameters, so when the client sends data

“ADD 3 4” + newline

The server receives an instance of cmdInfo for StringRequestInfo with the following attributes:

cmdInfo.Key = “ADD”;

cmdInfo.Data = “3 4”;

cmdInfo.Parameters = {“3 4”}

To better understand and understand, let’s look at the debugging parameters:

The results

See here if the StringRequestInfo instance is clear. In fact, SuperSocket does not only resolve these built-in command line protocols, the format of the request may be different in different business scenarios. In some protocols commands and parameters are delimited by characters other than Spaces, in which case we need to reset CommandLineProtocol’s CommandParser. The BasicCommandParser built into SuperSocket directly sets command names and parameters, and delimiters between parameters.

For example, command names and parameters are separated by colons (:), and parameters are separated by commas (,), for example, ADD:3,4. To do this, we simply instantiate BasicCommandParser with “:” and “,” and assign it to an instance of CommandLineProtocol as follows:

MyServer class change location:

If we want to define the request format in more depth, we can implement a TestRequestInfoParser class based on the interface IRequestInfoParser. Then when instantiation CommandLineReceiveFilterFactory to formulate a TestRequestInfoParser instances:

For example, change the format to HL:ECHO:data

 

Test results:

If we use the binary protocol in the SuperSocket, all received data will be translated into BinaryRequestInfo instances. There is no official description of the use of this protocol, so you can learn about it when you need to use it later.

 

The built-in command line protocol docs.supersocket.net/v1-6/zh-CN/…