Tor source code file analysis-Hibernation

This article introduces the TOR System sleep module. The code of the sleep module is in the source file hibernation. C. Simply put, its main function is to sleep the system at an appropriate time to prevent excessive consumption of system resources; or, at the right time, restart the system to serve the global service. In the default system configuration, the client's sleep module is disabled, that is, the client will never enter the sleep state. This is not the case with the worker Routing Server in the TOR system. They often need to set some policies and bandwidth for network services, so they need to limit their contributions to the TOR system. From the traffic perspective alone, some or servers may not be willing to allow their own data volume to exceed a very large range within a period of time. Therefore, when the or server runs its own tor program, it is configured to check the amount of data flowing over a fixed period of time. If the data volume is small, the server can tolerate it. If the data volume is very large, the server will put its TOR program into sleep state, providing a small number of services, or even not providing services.

Before talking about the sleep mechanism, you need to pay attention to the two configuration options in the configuration file: accountingmax and accountingstart. The server uses these two configuration items to configure the traffic range they can accept. We use the default situation as an example. Generally, a Tor Routing Server collects statistics on its traffic cycle for one month. In a month, the traffic allowed through its own TOR network is 1 GB, the preceding two configuration items can be configured based on the requirement that the cycle is month and the traffic is 1 GB. For details about how to configure in the configuration file, refer to the options in tor manual.

Here we will first analyze the global variables and some functions of the source file of the sleep module.

0. Overview

In the overview section, we simply paste the description of the file in the source file header, because it has clearly described the events and main work content to be handled by the file.

/*** \ File hibernate. C * \ brief functions to close listeners, stop allowing new circuits, * etc in preparation for closing down or going dormant; and to track * bandwidth and time intervals to know when to hibernate and when to * Stop hibernating. ** // * hibernating, Phase 1: // response generated when soft limit is about to exhaust traffic-send destroy in response to create cells-send end (Policy failed) in response to begin cells-close an OR conn when it has no circuitshibernating, Phase 2: // reaction to hard limit traffic depletion (entered when bandwidth hard limit reached) -Close all or/AP/exit Conns )*/

In short, whether or not the system sleep depends on the amount of system traffic in a specified period of time. The comment in the source file provides the following brief explanations about sleep and traffic statistics:

/* Fields for accounting logic. accounting Overview: ** accounting is designed to ensure that no more than n Bytes are sent in * either direction over a given interval (currently, one month, one week, or * One Day) we cocould * try to do this by choking our bandwidth to a trickle, but that * wocould make our streams useless. instead, we estimate what our * bandwidth usage will be, And guess how long w E'll Be Able To * provide that much bandwidth before hitting our limit. we then * choose a random time within the accounting interval to come up (so * that we don't get 50 tors running on the 1st of the month and none * on the 30th ). ** each interval runs as follows: ** 1. we guess our bandwidth usage, based on how much we used * last time. we choose a "wakeup time" within the interval to come u P. // randomly select a time point in the time range; * 2. until the chosen wakeup time, We hibernate. // remain dormant before the time point. When the time point is reached, wake up the system. * 3. we come up at the wakeup time, and provide bandwidth until we are * "very close" to running out. // The service is continuously provided after the system is awakened, knowing that the traffic is about to run out. * 4. then we go into low-bandwidth mode, and stop accepting new * connections, but provide bandwidth until we run out. // when the traffic is about to be exhausted, the new connection will not be accepted, and the service will continue for the existing connection until the traffic is exhausted; * 5. then we Hibernate until the end of the interval. // after the traffic is exhausted, the system enters the sleep state until the next cycle determines the system wake-up time. ** If the interval ends before we run out of bandwidth, we go back to * Step one .*/

1. Global Variables

/** Are we currently awake, asleep, running out of bandwidth, or shutting * down? */Static hibernate_state_t hibernate_state = hibernate_state_initial; // the current state of the system indicated by the current hibernation module/** if are hibernating, when do we plan to wake up? Set to 0 if we * Aren't hibernating. */static time_t hibernate_end_time = 0; // the end time of the Current sleep. If the current sleep is not in sleep state, the value is 0/** if we are shutting down, when do we plan finally exit? Set to 0 if * We Aren't shutting down. */static time_t shutdown_time = 0; // The final exit time when the instance is in the shutdown state.

All the following global variables are used to control and record the traffic period and related time. After understanding the rules for periodical running and traffic statistics in the overview, the following global variables should not be difficult to understand. Here, we will simply list them. Their specific purposes can be easily understood from English comments.

/** How many bytes have we read in this accounting interval? */static uint64_t n_bytes_read_in_interval = 0;/** How many bytes have we written in this accounting interval? */static uint64_t n_bytes_written_in_interval = 0;/** How many seconds have we been running this interval? */static uint32_t n_seconds_active_in_interval = 0;/** How many seconds were we active in this interval before we hit our soft * limit? */static int n_seconds_to_hit_soft_limit = 0;/** When in this interval was the soft limit hit. */static time_t soft_limit_hit_at = 0;/** How many bytes had we read/written when we hit the soft limit? */static uint64_t n_bytes_at_soft_limit = 0;/** When did this accounting interval start? */static time_t interval_start_time = 0;/** When will this accounting interval end? */static time_t interval_end_time = 0;/** How far into the accounting interval should we hibernate? */static time_t interval_wakeup_time = 0;/** How much bandwidth do we 'expect' to use per minute?  (0 if we have no * info from the last period.) */static uint64_t expected_bandwidth_usage = 0;/** What unit are we using for our accounting? */static time_unit_t cfg_unit = UNIT_MONTH;/** How many days,hours,minutes into each unit does our accounting interval * start? *//** @{ */static int cfg_start_day = 0,           cfg_start_hour = 0,           cfg_start_min = 0;/** @} */

2. interface function 2.1. Accounting

The accounting code is used to determine whether the system should be in sleep state or whether it should be awakened, so they are in the same file.

Configure_accounting

Initialize the traffic statistics submodule function;

Accounting_parse_options

Accounting_is_enabled

Accounting_get_interval_length

Function functions of the traffic statistics submodule: Use the configuration option to initialize the function, determine whether to enable the function of the traffic statistics module, and obtain the function of the traffic statistics time interval;

Accounting_run_housekeeping --> accounting_record_bandwidth_usage

Maintenance function of the traffic statistics submodule: The main function is to restart the subsystem at an appropriate time, change the server status and write it back to the hard disk (Mark dirty) Every 600 seconds );

Accounting_add_bytes

Main traffic statistics function functions of the traffic statistics submodule: Process traffic increase;

Getinfo_helper_accounting

The message query function provided by the traffic statistics submodule: this function can be used to obtain the current status of the submodule;

2.2. Hibernation

Consider_hibernation

Sleep control function: This function is called to determine whether the current traffic statistics of the system requires the system to enter the sleep state or to be awakened from the sleep state;

We_are_hibernating

Sleep judgment function: returns whether the system is in sleep state;

Hibernate_begin_shutdown

Disable the system function: when the system receives the SIGINT signal, it disables the entire system (including the traffic statistics module, of course ).