Netty-based chat system (ii) protocol customization----Login

In the previous article we discussed the basic process of chatting, then we now based on the process of the previous article began to define the protocol, if a friend has better suggestions, can be in the following reply to study the discussion, we say that the login is divided into two parts, the first part of the connection with the server phase, the second part of the verification phase, So first we will specify the protocol based on these 2 parts:

Connection phase:

{"ID": "xxxx", " #": "conn", "u": 1[email protected]/ios, "v": }

ID: The ID generated by the client

#: Expression of behavior, the popular meaning is the one that says, what do we do, this property is primarily the handler on the corresponding server

U: Here is the meaning of user information, in fact, this string represents 2 meaning, @ Before the user id,@ is the user's mobile version, we want to get the user's mobile version, separate write can also, but here feel no need to separate directly where together

V: The user's current version number of the software, mainly to check the user's phone on the current version of the

The user speaks the JSON sent to the server, then the server responds to the client, so here we also define the protocol format that the server side returns to the client

Response Connection phase:

{id ' # ssl "rar": "[up]", "IPs": "[]" }

ID: Nothing to say, the server-side generated ID

#: Corresponding to the handler, popular says that even if the action that represents the response, such as the connection phase when the user sends Act is conn, then the response back here is conn, which corresponds

SSL: Here we use an array, in fact, pre-use a value is not a problem, but later we may have a variety of encryption methods, so with the array

RAR: Here is also an array that represents the compression method of data transfer

IPs: This represents the list of idle servers, making it easy for users to choose a server with less pressure

Well, so far we've completed a conn phase, so the next step is the validation phase, and we'll go on to discuss the protocol.

Auth Stage:

{id ' # ' "p": "1", "SSL":2 }

ID: Same as client-generated ID

#: Expression of behavior, the popular meaning is the one that says, what do we do, this property is primarily the handler on the corresponding server

P: Indicates the password after encryption

SSL: Indicates which encryption method the user chooses to encrypt

Then the authentication may fail, then the server will return an error message, then the error message Protocol:

Auth Failure phase:

{"ID": "xxxx", "#": "auth", "EC": 1, "em": " success / failure " }

ID: Server Generation ID

#: Corresponding to the handler, popular says that even if the action that represents the response, such as the connection phase when the user sends Act is AUTH, then the response back here is auth, which corresponds

Ec:errorcode, error code

Em:errormessage, error message

Auth Success Stage:

{id ' "#": "auth" }

In fact, not only can be used for Auth success, all the success of the agreement can be used, then this is our login phase of the agreement, about the chat protocol we take a break, in the next article in detail, welcome everyone to discuss