[Post] neural network programming BASICS (2): What are we writing when we are reading and writing socket?

Introduction to neural network programming (2): What are we writing during socket writing? Http://www.52im.net/thread-1732-1-1.html

1. Introduction This article is followed by the first article titled Neural Network Programming (I): Follow the animation to learn TCP three-way handshakes and four waves, and continue to learn neural network programming knowledge ^_^. Socket socket is a concept that most programmers are very familiar with. It is the foundation of computer network programming. TCP/UDP depends on it for sending and receiving messages. The Web server we are familiar with depends on it at the underlying layer. The MySQL relational database and redis memory database we use depend on it at the underlying layer. We also rely on it for chatting with others. When we play online games, we rely on it. Readers can read this article because it supports Network Communication silently. This article still tries to use animated images to explain this knowledge point in a "Brainless" manner (haha). It is expected that readers can understand the data read and write nature of socket communication more simply and intuitively. Reminder: If your network speed is slow, loading GIF animation may be slow. Please wait. 2. About the author <Ignore_js_op> Qian wenpin (old money): Graduated from Huazhong University of Science and Technology in computer science and technology, and has been a veteran of Internet distributed high Concurrency Technology for ten years. Currently, he is a senior backend engineer of shouxi technology. Proficient in Java, Python, golang, and other computer languages, developed games, made websites, wrote message push systems, and MySQL middleware, implemented open-source ORM frameworks, Web frameworks, and RPC frameworks. Author's GitHub: https://github.com/pyloque 3. series of articles This is the first article in the series. The outline of this series is as follows: Neural Network Programming (I): Follow the animation to learn TCP three-way handshake and four waves Introduction to neural network programming (2): What are we writing when we are reading and writing socket? (This article) Introduction to neural network programming (III): knowledge required for HTTP protocol Introduction to neural network programming (iv): A quick understanding of server push for HTTP/2 Neural Network Programming entry (V): ping command used every day. What is it? 4. simple process of socket read/write When the client and server use the TCP protocol for communication, the client encapsulates a request object req, serializes the request object req into a byte array, and then sends the byte array to the server through Socket socket, the server reads the byte array through socket, deserializes it into the request object req for processing, and after processing, generates a response corresponding to the res, serializes the response object res into a byte array, then, the client sends its own array to the client through the socket to read its own array and deserialize it into a response object. <Ignore_js_op> Communication frameworks often hide the serialization process. What we see is that the request object req and response object res run between the client and the server. Maybe you think this process is quite simple and easy to understand, but in fact, a series of events are beyond the imagination of most of you. The actual communication process is much more complex than the figure above. You may ask, do we need to know more about it? Can we just use it directly? Years of Experience in the internet technology service industry tell me that if you do not know the underlying mechanism, you will not understand why the reading and writing of Socket socket may encounter various strange issues, why is it sometimes blocked, sometimes not blocked, and sometimes an error is reported? Why is there a problem with Sticking half-pack? What is NiO? What is it particularly new? Understanding these problems requires you to understand the underlying mechanism. 5. Detailed Process Analysis of socket read/write To facilitate your understanding of the underlying communication layer, I spent some time doing the following animation. It does not cover the full picture of the underlying details, but it is sufficient to understand the working mechanism of sockets. Take a closer look at the animation, which will be explained later. <Ignore_js_op> The socket we usually use is actually a reference (an object ID), which is actually placed in the operating system kernel. This socket object has two important buffer structures: read buffer and write buffer. They are all arrays of limited sizes. When we write a byte array (the serialized request message object req) to the socket of the client, the byte array is copied to the write buffer of the socket object in the kernel area, the kernel network module will have a separate thread responsible for constantly copying the write buffer data to the NIC hardware, and then the NIC hardware will send the data to the NIC, it is finally delivered to the NIC hardware of the server. Similarly, the network module of the server kernel will have a separate thread constantly copy the received data to the read buffer of the socket and wait for the user layer to read it. The user process of the server copies the data in the read buffer to the user program memory through the read method referenced by the socket for deserialization into a request object for processing. The server then sends the processed response object to the client in the opposite process, which is not described here. 5.1 detailed process: Blocking We noticed that the write buffer space is limited, so if the application writes too fast to the socket, the space will be full. Once the space is full, the write operation will be blocked until there is enough space available. However, with NiO (non-blocking Io), write operations can also be non-blocking, and the number of writes can be determined by the return value, user programs that have not been written will cache the content and will continue to write again later. We also noticed that the read buffer content may be empty. In this way, the read operations on the socket (generally reading a fixed-length byte array) will also be blocked until the read buffer has enough content (filled with full byte arrays) to return. With NiO, there is no need to block the number of reads. If the read is insufficient, the system will continue to try reading the data later. 5.2 detailed process: ACK So the figure above shows all the socket processes? Obviously not, the data validation process (ACK) is completely invisible. For example, after the content in the write buffer is copied to the network card, the copied content will not be removed immediately from the write buffer, but will not be removed until the other side's ack comes. If the network condition is not good, Ack will not be able to come, and the write buffer will soon be full. 5.3 detailed process: Baotou Careful students may notice that the message req in the figure is converted to an upper-case req when it is copied to the NIC. Why? Because these two items are not exactly the same. The kernel Network Module transmits messages in the buffer zone in blocks. If the buffer zone contains too much content, messages are split into multiple independent small message packets. Additionally, additional header information must be appended to each packet, such as the source NIC address, target NIC address, and message serial number, after receiving the message packets, the packets need to be re-sorted and assembled to the header before they are thrown into the read buffer. These complex detailed processes are very difficult to present on the animation. 5.4 detailed process: Speed Another problem is that if the read buffer is full, what should I do? What should I do if the NIC receives the message from the other party? The general practice is to discard the ACK and send the message again if the Ack is delayed. Why is the buffer full? Because the message recipient processes slowly and the message produced by the sender is too fast, the TCP protocol will have a dynamic window adjustment algorithm to limit the sending rate of the sender, so that the sending and receiving efficiency tends to be matched. If the UDP protocol is used, the message will be lost. More complicated details about the internal implementation of network protocols need to be further explored. Appendix 1: a selection of similar articles If you think this series of articles is too basic, you can read the following series: Introduction to network programming lazy (1): quick understanding of network communication protocols (Part 1) Introduction to network programming lazy (2): quick understanding of network communication protocols (Part II) Introduction to network programming lazy (3): A quick understanding of TCP is enough. Introduction to network programming lazy (4): quick understanding of the differences between TCP and UDP Introduction to network programming lazy (V): Quickly Understanding why UDP is sometimes more advantageous than TCP Getting started with network programming lazy (6): getting started with the most popular functions of hubs, switches, and routers in history Introduction to network programming lazy (7): a simple introduction to HTTP The Unknown network programming series is a high-order read. The series of directories are as follows: Unknown network programming (I): Analysis of difficult and Miscellaneous problems in TCP protocol (part I) Unknown network programming (II): An Analysis of the intractable diseases in TCP protocol (Part II) Unknown network programming (III): Why does time_wait and close_wait occur when TCP connections are closed? Unknown network programming (4): In-depth Study and Analysis of Abnormal TCP Shutdown Unknown network programming (V): UDP connectivity and load balancing Unknown network programming (6): a deep understanding of the UDP protocol and using it For more information about mobile network features and optimization methods, see: Summary of Optimization Methods for short network connections on modern mobile terminals: Request speed, weak network adaptation, and security assurance Mobile im developers must read (1): easy to understand and understand the "weakness" and "slowness" of Mobile Networks Mobile im developers must read (2): summary of the most comprehensive optimization methods for mobile and weak networks in history Appendix 2: References TCP/IP explanation-Chapter 11th UDP: User Datagram Protocol TCP/IP explanation-Chapter 17th TCP: Transmission Control Protocol TCP/IP explanation-Chapter 18th TCP connection establishment and Termination TCP/IP explanation-Chapter 21st TCP timeout and retransmission Easy to understand-in-depth understanding of TCP protocol (I): Theoretical Basis Easy to understand-a deep understanding of TCP protocol (below): RTT, sliding window, congestion handling Classic Theory: three handshakes of TCP protocol and four handshakes Theory and Practice: Wireshark packet capture analysis TCP three handshakes and four waves Computer network communication protocol diagram (Chinese Simplified Chinese Version) High-Performance Network Programming (I): How many concurrent TCP connections can a single server have? High-Performance Network Programming (ii): The famous c10k concurrent connection problem in the last 10 years High-Performance Network Programming (III): Next 10 years, it's time to consider the c10m concurrency issue. High-Performance Network Programming (iv): Theoretical Exploration of high-performance network applications from c10k to c10m Brief Introduction to the differences between transport layer protocol TCP and UDP Why does QQ use UDP rather than TCP? Mobile instant messaging protocol selection: UDP or TCP? Past Technical Events: TCP/IP protocols that have changed the world (precious multiple pictures, cell phone tips) What is the maximum size of a packet in UDP? Introduction to the AIO principle of the next-generation network programming model in Java and AIO in Linux NIO framework entry (1): Demonstration of netty4-based UDP bidirectional communication on the server NIO framework entry (II): demo of UDP two-way communication on the server based on mina2 Introduction to NiO framework (III): cross-platform UDP bidirectional communication between iOS, mina2, and netty4 Introduction to NiO framework (iv): cross-platform UDP bidirectional communication between Android, mina2, and netty4 P2P technology (1): Nat-detailed principles and P2P Introduction P2P Technology (II): P2P NAT traversal (hitting holes) Solution P2P Technology (III): P2P technology stun, turn, and ice Easy to understand: quick understanding of NAT penetration principles in P2P Technology > More articles of the same type ......

Source: instant messaging network-Instant Messaging developer community!

[Post] neural network programming BASICS (2): What are we writing when we are reading and writing socket?