Shulou(Shulou.com)06/02 Report--

20.17. SocketServer-- network framework

Note: SocketServer is renamed to socketserver in python 3. When you convert the code to a version of python 3, the 2to3 tool automatically imports adaptations.

Source code: Lib/SocketServer.py

The SocketServer module simplifies the steps of writing web server applications. It has four specific basic server classes:

Class SocketServer.TCPServer (server_address, RequestHandlerClass, bind_and_activate=True)

This class uses the TCP network protocol to provide continuous streaming data between the client and the server. If bind_and_activate is true, the constructor automatically calls the server_bind () and server_activate () methods. The remaining parameters are passed to the base class BaseServer.

Class SocketServer.UDPServer (server_address, RequestHandlerClass, bind_and_activate=True)

This class uses data packets, and the packets are discrete; in the process of data transmission, the order of packet arrival may be out of order or may be lost. Class parameters are the same as TCPServer.

Class SocketServer.UnixStreamServer (server_address, RequestHandlerClass, bind_and_activate=True) class SocketServer.UnixDatagramServer (server_address, RequestHandlerClass, bind_and_activate=True)

These two classes are not used as frequently as the first two classes, and their usage is similar, except that they use sockets; in the Unix domain, which cannot be used on non-Unix platforms. Class parameters are the same as TCPServer.

All the above four classes handle the network request synchronously, that is, the request must be processed before the next request can be processed. If the request takes a long time, such as a large amount of computation, or the client processing is slow due to too much data, it is not appropriate. The solution is to create separate processes or threads to respond to each request; the mix-in classes ForkingMixIn and ThreadIingMixin can support this asynchronous behavior.

Creating a server takes several steps. First, you write a request parsing class that inherits from the base class BaseRequestHandler and overwrites the base class's handle () method, which handles every request that enters the server. Second, you must create an object of the server class and pass the server address and request resolution class to the object. The server object's handle_request () or server_forever () methods are then called to process one or more requests. Finally, the server_close () method is called to close the socket.

If you want to inherit the base class ThreadingMixIn to complete multithreaded connection behavior, you need to explicitly declare what the thread will do in the event of a sudden shutdown. The ThreadingMixIn class has a property called daemon_threads that indicates whether the server should wait if the thread terminates. If you want threads to process automatically, you must explicitly set this flag; by default, its value is False, which means that Python exits only when all threads created by ThreadingMixIn exit.

Regardless of the type of network protocol used, the server class has the same external methods and properties.

20.17.1. Key points of server creation

There are five classes in the inherited relationship table, of which four types represent four synchronous server classes.

+-+ | BaseServer | +-+ | TCPServer |-> | UnixStreamServer | +-+-+ | UDPServer + +-+ | UDPServer |-> | UnixDatagramServer | +-+

Note that UnixDatagramServer inherits from UDPServer, not that the only difference between UnixStreamServer--IP and Unix streaming servers is the address family, where the two Unix servers use the same address family.

Class SocketServer.ForkingMixInclass SocketServer.ThreadingMixIn

Each type of server can use the mix-in class to create multiple processes or threads. For example, the following example creates a ThreadingUDPServer class:

Class ThreadingUDPServer (ThreadingMixIn, UDPServer): pass

Note that the mix-in class comes first because it overrides a method in UDPServer. Setting different properties can also modify the behavior of the underlying server.

The following ForkingMixIn and Forking classes can only be used on the POSIX platform and support fork ().

Class SocketServer.ForkingTCPServerclass SocketServer.ForkingUDPServerclass SocketServer.ThreadingTCPServerclass SocketServer.ThreadingUDPServer

These four classes are predefined mix-in classes.

To provide services to the client, you must derive a subclass from the BaseRequestHandler class and override the handle () method. You can then provide that type of service by merging some type of server with a BaseRequestHandler subclass. The request parsing classes for message services and streaming services are definitely different. You can inherit the StreamRequestHandler or DatagramRequestHandler classes to hide this difference.

Of course, you can also play on your own. For example, if the state of the service in memory can be modified by different requests, and if the modification of the child process can not reach the initial state of the parent process and passed to the child process, then there is no point in creating a child process of a server. In this case, you can create a child thread of the server, but you may need to lock it to ensure the integrity of the shared data.

On the other hand, if you create a HTTP server, all its data is stored on external media (such as the file system), then the synchronization server basically can only "waste" on the service when parsing a request that takes a long time because the client is slow to receive data. At this point, it is appropriate to create a child thread or child process.

In some cases, based on the request data, it is possible to synchronize part of the request and process the rest in a child process. You can create a synchronization server, and fork a child process in the handle () method to do the above.

In an environment where neither multithreading nor fork is supported (or where they are both too expensive or inappropriate), another way to parse multiple simultaneous requests is to maintain an explicit table that records partially completed requests, and uses the select () method to determine which one is about to work (or needs to parse a new request). This is especially important for streaming services that each client may connect for a long time (provided that multithreading or multiprocesses cannot be used). Take a look at the asyncore module, which mentions another way to deal with this situation.

20.17.2. Server object class SocketServer.BaseServer (server_address, RequestHandlerClass)

BaseServer is the parent class of all server objects in the module. It defines the following interfaces, but most of these methods do not need to be implemented because they have been implemented in subclasses. Two parameters are required, which are stored in the server_address and RequestHandlerClass attributes, respectively.

Fileno ()

Gets the socket file descriptor that the server is listening for. The most common practice of this method is to pass the return value to the select.select () method, which allows you to listen to multiple servers in the same process.

Handle_request ()

Handle a single request. This function calls the following methods in order: get_request (), verify_request (), and process_request (). If the user-supplied request parsing class handle () method throws an exception, the server calls the handle_error () method. If the request is not received within timeout seconds, the handle_timeout () method is called and handle_request () returns.

Serve_forever (poll_interval=0.5

Parse the request until a displayed shutdown () request is received. Check to see if a shutdown request is received every poll_interval second. The timeout attribute is ignored. If you need to perform periodic tasks, please execute them in another thread.

Shutdown ()

Tell serve_forever () to stop the loop and wait for serve_forever () to stop before returning.

Server_close ()

Clean up the server. Can be overwritten by subclasses.

Address_family

The protocol family to which the server's socket belongs. Common values are socket.AF_INET and socket.AF_UNIX

RequestHandlerClass

A user-provided request parsing class; each request creates a parsing class object.

Server_address

The address that the server is listening to. The format of the address value depends on the protocol family; refer to the documentation of the socket module for more details. In Internet protocol, a server address is a tuple that contains a specified address string and an integer port number: for example ('127.0.0.1)

Socket

The socket object used by the server to listen for requests

The server class supports the following class properties:

Allow_resue_address

Whether or not the server allows address reuse, this value defaults to False and can be modified in subclasses.

Request_queue_size

The size of the request queue. If it takes a long time to process a single request, when the server is busy, any incoming requests will enter a queue until the number reaches request_queue_size. Once the queue is full, subsequent requests will receive "Connection denied" error feedback. The default value is usually 5, but can be modified in subclasses.

Socket_type

The type of socket used by the server; usually take socket.SOCK_STREAM and socket.SOCK_DGRAM

Timeout

The timeout period (in seconds), or None if no timeout setting is required. If handle_request () does not receive a request within the timeout period, the handle_timeout () method is called.

There are several server methods that can be overridden in subclasses, such as TCPServer; these methods are of little use to consumers of server objects.

Finish_request ()

Create a RequestHandlerClass object and actually process the request, calling the method that parses the class handle ().

Get_request ()

You must accept a socket request and return a tuple, including a new socket object for communicating with the client and the client address

Handle_error (request, client_address)

If the handle () function of the RequestHandlerClass object throws an exception, handle_error () is called. The default behavior of handle_error is to print the exception call stack to the standard output terminal and proceed to parse the next request.

Handle_timeout ()

This function is called when the timeout property is not None, but a valid value, and no request is received after the timeout time has elapsed. The default behavior of handle_timeout is that the child processes of one server are used to collect the status of any exited child processes, while this method does nothing in multiple threads of the server.

Process_request (request, client_addresss)

Call finish_request () to create a RequestHandlerClass object. If necessary, this function creates a new process or thread to parse the request; the ForkingMixIn and ThreadingMixIn classes do this.

Server_activate ()

Called by the constructor of the class to activate the server. By default, server_activate () in the TCP server only calls the listen () method, which is used to listen on the server's socket object. This method can be overridden by subclasses.

Server_bind ()

Called by the constructor of the class to bind the socket object to the specified address. This method can be overridden by subclasses.

Verify_request (request, client_address)

A Boolean must be returned; if the value is True, the request is processed, otherwise it is rejected. Verify_request can be rewritten by subclasses, and with this method, the server can implement access control. This method returns True by default.

20.17.3. Request to parse the class object class SocketServer.BaseRequestHandler

It is the parent class of all request parsing class objects. There are the following interfaces. The subclass of the request parsing class must implement the handle () method, and other methods can be overridden. A subclass object is created for each request.

Setup ()

Called before the handle () function to initialize the behavior. Do nothing by default

Handle ()

This function must do all the expected work to serve the request. Do nothing by default. Handle () can use several instance properties; request the instance self.request; client address self.client_address; server instance self.server to access the server's information.

The self.request type of message service or streaming service is different. For streaming services, self.request is a socket object; for message services, self.request is a pair of strings plus socket.

Finish ()

All cleanup operations are performed after the handle () method call. Do nothing by default. If setup () throws an exception, the function will not be executed.

Class SocketServer.StreamRequestHandler

Class SocketServer.DatagramRequestHandler

Subclasses of these BaseRequestHandler override the setup () and finish () methods, providing both self.rfile and self.wfile properties. The self.rfile is readable and is used to get the request data; the self.wfile property is writable and is used to provide data to the client.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.