Python Standard library Socketserver Learning

Introduction: Daniel often says reading the source code is a very inefficient way to learn. But for my generation, reading source code is a good way to master programming ideas and coding norms. In short, read the source code is not omnipotent, do not read the source is absolutely impossible.

Socketserver is a very representative library in the standard library. It is based on the socket to provide a quick set of socket server framework, and through the mix-in of the skills of the single-threaded server to evolve into multi-threaded or multi-process server. There are many classes in socketserver.py, and the following one introduces and describes the relationship between them.

Baseserver, TCPServer, Udpserver, the former is the parent class of the latter two. Implements the method that TCP and UDP servers can share in the parent class, and leaves abstract classes that need to be implemented in subclasses. Therefore, in practice, we should not generally inherit the Baseserver class unless you are implementing or overloading certain methods for yourself. In addition, Unixstreamserver and unixdatagramserver inherit from TCPServer and Udpserver respectively. The two classes with the Unix typeface are the servers used to build the local socket on the *nix (local socket access is faster but can only be used for inter-process communication between native)

Next is the Forkingmixin and threadingmixin two hybrid classes, which provide a new implementation of the Process_request method in the server class that will open a new process each time the user connects, and the latter will open the new thread. To allow the server class to implement concurrent processing, use multiple inheritance only. or directly using a mixture of

Class Forkingudpserver (Forkingmixin, udpserver): Pass

Class Forkingtcpserver (Forkingmixin, tcpserver): Pass

Class Threadingudpserver (ThreadingMixIn, udpserver): Pass

Class Threadingtcpserver (ThreadingMixIn, tcpserver): Pass

Last but not the Baserequesthandler, Streamrequesthandler, Datagramrequesthandler, as with the server, the former is the parent class used to provide a common method

Usually when using socketserver, we only instantiate an appropriate server class by ourselves and pass its listening IP, port on instantiation, and the class that was previously inherited from a RequestHandler (the Hanle method needs to be implemented by itself. As the server's request processor)

Special attention is needed here:

1.IP and ports are passed as a tuple instead of two separate parameters.

2. Each client connection will be closed after the Hanle method runs and you will need to rewrite the Def shutdown_request (self, request) method in the server if you do not want to close it

___________________ I'm a gorgeous split line ________________________

It can be said that the standard library is very convenient to use, but there are still some shortcomings in the function.

1. It does not provide communication mechanisms between the individual Hanle instances, so client-to-peer messaging still requires implementing an observer model on its own.

But it also seems to be more than Socketserver's job. We can do it ourselves, or we can use Python-message, a domestic third-party library, to do message-based programming between threads.

2. It provides a multithreaded multi-process solution, but server-per-access with no asynchronous scenario is blocked

I feel very sorry about this, but this library is not too complex, big not to write an asynchronous Socketserver bar, self-clothed!

Because it is the interpretation of the source code, so this article does not put any code. The reader can go through the standard library and look at it, and the comments are really great.

