Details of TCP/IP 2: Implementation-Route Selection

A process uses a plug-in the routing domain to send and receive routing packets. A pf_route

And a sock_raw plug-in type. This process can send the following five optional packets to the kernel:

1. rtm_add: Add a new route.

2. rtm_delete: delete an existing route.

3. rtm_get: obtains all information about a route.

4. rtm_change: Change the gateway, interface, or measurement of an existing route.

5. rtm_lock: indicates which variable should not be modified by the kernel.

This chapter describes the selection fields, the routing control blocks created for each selection plug-in, the functions used to process the packets generated by the process (route_output), and the routing packets sent to

Or multiple process functions (raw_input), and different functions that support all plug-in operations on an optional plug-in.

1. routedomain and protosw Structure

Lists the domain structure of the pf_route domain called routedomain.

Unlike Internet domains that support multiple protocols (TCP, UDP, and ICMP), only one protocol of the sock_raw type is supported in the routing domain. List

Protocol conversion for the pf_route domain.

2. Optional control blocks

When you create an optional plug-in by calling the following method,

Socket (pf_route, sock_raw, Protocol );

Assign a routing control block to a corresponding pru_attach request of the Protocol's user request function (route_usrreq) and connect it to the plug-in structure.

The Protocol Parameter limits the type of messages sent to the process on the plug-in to a specific family. For example, if the protocol parameter is described as af_inet,

Only selected packets containing the Internet address will be sent to this process.

We call these structures a routing control block instead of a raw control block, which shows the definition of the rawcb structure.

In addition, a global structure with the same name is assigned, rawcb, as the header of the two-way linked list, as shown in.

3. route_output Function

When a pru_send request is sent to the user request function of the protocol, route_output is called. This is a process that performs some operations on a routing plug-in.

. The approximate process of the function is as follows:

4. raw_input Function

All routing packets sent to a process, including those generated by the kernel and generated by the process, are passed to raw_input, and the latter chooses to receive the packet

Process. The approximate process of this function is as follows:

1. Compare the address families and protocols. Cyclically traverse each routing control block to find a match.

2. Compare local and external addresses. The two tests compare the local and external addresses in the control block.

3. Add messages to the receiving cache of the plug-in. Add a copy of the packet to the receiving cache of the plug-in, and wait for any process in the receiving cache.

Will be awakened.

5. route_usrreq Function

Route_usrreq is the user request function of the routing protocol. It is called by different operations. The approximate process of the function is as follows:

1. For pru_attach: allocate control blocks

When a process calls a socket, A pru_attach request is sent. Allocate memory for an optional control block.

2. If it is pru_detach: the counter is decreasing

The close system calls the pru_detach request. If the Socket Structure points to a protocol control block, two counters in the route_cb structure are reduced by 1: One

Is any_count; the other is a counter based on this protocol.

3. process the request. The raw_usrreq function is called to further process the pru_xxx request.

4. Increase the number of counters.

5. Connect the plug-in. Connect to the new plug-in permanently to receive route selection packets from the pf_route family.

6. so_useloopback is enabled by default. Enable the so_useloopback plug-in option. This is a default enabled plug-in option.

6. raw_usrreq Function

Raw_usrreq completes most of the work of processing user requests in the routing domain. It is called by the route_usrreq function. The processing of user requests is divided into these two functions,

It is because some other protocols call raw_usrreq instead of route_userreq. Raw_usrreq does not want to be a pr_usrreq function. Instead, it is

Common subroutines called by different pr_usrreq functions.

The function mainly processes various pru_xxx requests:

The result of a socket system call when a pru_attach request is sent. The request calls the raw_attach function to connect the control block to the two-way linked list.

Pru_detach is a request sent by the close system call. This request will call the raw_detach function to delete the control block from the two-way linked list.

The pru_connect2 request comes from the socketpair System Call and is not supported in the routing selection domain.

The pru_disconnect request is sent by close before the pru_detach request, because an optional plug-in is always connected. This request will call raw_disconnect to release the control block of the plug-in.

When a pru_shutdown request is sent by the shutdown system, the request will call the socantsendmore function to prohibit subsequent write operations.

When a pru_send request is sent by sosend, The pr_output function is called, that is, the route_output function.

If a pru_abort request is sent, the control block is disconnected, the plug is released, and then disconnected.

If a pru_sense request is sent by the fstat system, the function returns OK.

Pru_rcvoob, pru_rcvd, pru_listen, pru_accept, and pru_sendoob requests are not supported.

Pru_sockaddr and pru_peeraddr requests are called by the getsockname and getpeername systems respectively. The former always returns an error,

The bind system call with the local address is not supported in the routing domain. The latter always returns the contents of route_src, which is composed

Route_usrreq is set as an external address.

Details of TCP/IP 2: Implementation-Route Selection