oioioi.workers.management.commands.start_receive_from_workers

Module Contents

Classes

ServerHandler

HTTP request handler base class.

Server

Base class for various socket-based server classes.

Command

The base class from which all management commands ultimately
class oioioi.workers.management.commands.start_receive_from_workers.ServerHandler(request, client_address, server)[source]

Bases: http.server.BaseHTTPRequestHandler

HTTP request handler base class.

The following explanation of HTTP serves to guide you through the code as well as to expose any misunderstandings I may have about HTTP (so you don’t need to read the code to figure out I’m wrong :-).

HTTP (HyperText Transfer Protocol) is an extensible protocol on top of a reliable stream transport (e.g. TCP/IP). The protocol recognizes three parts to a request:

  1. One line identifying the request type and path

  2. An optional set of RFC-822-style headers

  3. An optional data part

The headers and data are separated by a blank line.

The first line of the request has the form

<command> <path> <version>

where <command> is a (case-sensitive) keyword such as GET or POST, <path> is a string containing path information for the request, and <version> should be the string “HTTP/1.0” or “HTTP/1.1”. <path> is encoded using the URL encoding scheme (using %xx to signify the ASCII character with hex code xx).

The specification specifies that lines are separated by CRLF but for compatibility with the widest range of clients recommends servers also handle LF. Similarly, whitespace in the request line is treated sensibly (allowing multiple spaces between components and allowing trailing whitespace).

Similarly, for output, lines ought to be separated by CRLF pairs but most clients grok LF characters just fine.

If the first line of the request has the form

<command> <path>

(i.e. <version> is left out) then this is assumed to be an HTTP 0.9 request; this form has no optional headers and data part and the reply consists of just the data.

The reply form of the HTTP 1.x protocol again has three parts:

  1. One line giving the response code

  2. An optional set of RFC-822-style headers

  3. The data

Again, the headers and data are separated by a blank line.

The response code line has the form

<version> <responsecode> <responsestring>

where <version> is the protocol version (“HTTP/1.0” or “HTTP/1.1”), <responsecode> is a 3-digit response code indicating success or failure of the request, and <responsestring> is an optional human-readable string explaining what the response code means.

This server parses the request and the headers, and then calls a function specific to the request type (<command>). Specifically, a request SPAM will be handled by a method do_SPAM(). If no such method exists the server sends an error response to the client. If it exists, it is called with no arguments:

do_SPAM()

Note that the request name is case sensitive (i.e. SPAM and spam are different requests).

The various request details are stored in instance variables:

  • client_address is the client IP address in the form (host,

port);

  • command, path and version are the broken-down request line;

  • headers is an instance of email.message.Message (or a derived

class) containing the header information;

  • rfile is a file object open for reading positioned at the

start of the optional input data part;

  • wfile is a file object open for writing.

IT IS IMPORTANT TO ADHERE TO THE PROTOCOL FOR WRITING!

The first thing to be written must be the response line. Then follow 0 or more header lines, then a blank line, and then the actual data (if any). The meaning of the header lines depends on the command executed by the server; in most cases, when data is returned, there should be at least one header line of the form

Content-type: <type>/<subtype>

where <type> and <subtype> should be registered MIME types, e.g. “text/html” or “text/plain”.

do_GET()[source]
do_POST()[source]
class oioioi.workers.management.commands.start_receive_from_workers.Server(server_address, RequestHandlerClass, bind_and_activate=True)[source]

Bases: socketserver.TCPServer

Base class for various socket-based server classes.

Defaults to synchronous IP stream (i.e., TCP).

Methods for the caller:

  • __init__(server_address, RequestHandlerClass, bind_and_activate=True)

  • serve_forever(poll_interval=0.5)

  • shutdown()

  • handle_request() # if you don’t use serve_forever()

  • fileno() -> int # for selector

Methods that may be overridden:

  • server_bind()

  • server_activate()

  • get_request() -> request, client_address

  • handle_timeout()

  • verify_request(request, client_address)

  • process_request(request, client_address)

  • shutdown_request(request)

  • close_request(request)

  • handle_error()

Methods for derived classes:

  • finish_request(request, client_address)

Class variables that may be overridden by derived classes or instances:

  • timeout

  • address_family

  • socket_type

  • request_queue_size (only for stream sockets)

  • allow_reuse_address

Instance variables:

  • server_address

  • RequestHandlerClass

  • socket

allow_reuse_address = True
class oioioi.workers.management.commands.start_receive_from_workers.Command(stdout=None, stderr=None, no_color=False, force_color=False)[source]

Bases: django.core.management.base.BaseCommand

The base class from which all management commands ultimately derive.

Use this class if you want access to all of the mechanisms which parse the command-line arguments and work out what code to call in response; if you don’t need to change any of that behavior, consider using one of the subclasses defined in this file.

If you are interested in overriding/customizing various aspects of the command-parsing and -execution behavior, the normal flow works as follows:

  1. django-admin or manage.py loads the command class and calls its run_from_argv() method.

  2. The run_from_argv() method calls create_parser() to get an ArgumentParser for the arguments, parses them, performs any environment changes requested by options like pythonpath, and then calls the execute() method, passing the parsed arguments.

  3. The execute() method attempts to carry out the command by calling the handle() method with the parsed arguments; any output produced by handle() will be printed to standard output and, if the command is intended to produce a block of SQL statements, will be wrapped in BEGIN and COMMIT.

  4. If handle() or execute() raised any exception (e.g. CommandError), run_from_argv() will instead print an error message to stderr.

Thus, the handle() method is typically the starting point for subclasses; many built-in commands and command types either place all of their logic in handle(), or perform some additional parsing work in handle() and then delegate from it to more specialized methods as needed.

Several attributes affect behavior at various steps along the way:

help

A short description of the command, which will be printed in help messages.

output_transaction

A boolean indicating whether the command outputs SQL statements; if True, the output will automatically be wrapped with BEGIN; and COMMIT;. Default value is False.

requires_migrations_checks

A boolean; if True, the command prints a warning if the set of migrations on disk don’t match the migrations in the database.

requires_system_checks

A list or tuple of tags, e.g. [Tags.staticfiles, Tags.models]. System checks registered in the chosen tags will be checked for errors prior to executing the command. The value ‘__all__’ can be used to specify that all system checks should be performed. Default value is ‘__all__’.

To validate an individual application’s models rather than all applications’ models, call self.check(app_configs) from handle(), where app_configs is the list of application’s configuration provided by the app registry.

stealth_options

A tuple of any options the command uses which aren’t defined by the argument parser.

handle(*args, **options)[source]

The actual logic of the command. Subclasses must implement this method.