Clients and servers are involved in almost all projects. Communication between the client and the server is a common but problematic technical problem.
First, there are persistent connections and short connections. First, let's look at the concept.
Persistent connection short connection is just a conceptual problem. As long as you know its concept, it is not a special thing:
Persistent connection: the system communication connection is maintained after it is established.
Short connection: the connection is established only when the system needs to send messages to each other (initiated by the client). The connection is closed after the request message is responded;
Communication entities use persistent connections. Generally, heartbeat messages need to be defined and sent regularly to check whether links between systems are abnormal. Heartbeat messages are sent at intervals. If heartbeat messages are not received for a certain number of times, this indicates that the connection is faulty and the connection needs to be closed and re-established.
The specific Heartbeat message format, as well as the sending interval, and the number of times the Heartbeat message is not received, the link is considered abnormal, and whether the data department counts as a heartbeat message (if some systems receive a packet, the heartbeat timer is cleared, which is equivalent to a packet in the system as a heartbeat message). Both Ends Need to negotiate. For example, the smpp protocol used by GSM to connect Short Message Centers with other network entities requires a persistent connection.
Obviously, persistent connections are more complex. For the server, you must manage connected clients and check the heartbeat packets. Many service servers use persistent connections, while interface servers generally use transient connections.
Second, data synchronization and asynchronous requests.
After the client requests to the server, the client can wait for the result to be returned, and then process other tasks. You can also put the request in the queue and continue to do other tasks. After a result is returned, processing. Here is the question of synchronization and Asynchronization.
In general, the synchronization wait also has a time-out period, so you cannot keep waiting. In asynchronous processing, there will be a message queue and a request queue. When a message is returned from the server, it is placed in the message queue. Another thread processes the messages in the message queue and processes the data in the Request queue.
In addition, it is blocking and non-blocking.
The blocking result is that the thread will wait until the result is returned. If it is not blocked, only the request is sent without waiting for the result.
In many cases, asynchronous and non-blocking are used to improve processing performance and efficient resource usage.
Finally, it is the packet. Data packets are defined by yourself. Generally there are two types: Data Structure and XML data.
The two have their own advantages and disadvantages. For the data structure, the internal processing of the program is relatively easy, but it is not so good in terms of compatibility with multiple versions. For example, if fields are added to the structure, problems may occur during the processing of lower versions. XML data has good compatibility. You can only care about the fields you want, rather than those that you don't care about. Therefore, it is better for version compatibility. Therefore, XML data is widely used. XML data is commonly used in JSON, and C ++, Java, and Android support the data. In addition, encryption is performed during transmission. Of course, for cross-platform systems, we need to consider the issue of byte order.
Finally, let's summarize:
1. Connection Mode: persistent connection and short connection.
2. synchronous and asynchronous data requests.
3. Blocking and non-blocking.
4 packets: Protocol, encryption, and byte order.
Reprinted please indicate original link: http://blog.csdn.net/wujunokay/article/details/38211079