Implementation of TCP/IP under Windows

The Windows implementation of the TCP/IP protocol is built on the OSI foundation of the previous blog post. User Configuration is implemented by Ws2_32.dll and some other service provider DLLs, where Ws2_32.dll is a framework that can accommodate many service providers, which are actually the implementations of various protocols, such as the more common TCP/IP protocol, the IPX protocol. The service implementation of TCP/IP protocol is done by Msafd.dll and Mswsock.dll. Hkey_local_machine\system\currentcontrolset\services\winsock2, the Protocol (service) and some other information are recorded under the registration form.

In the case of TCP/IP, we generally use the POSIX standard socket interface to complete the functionality of our application, which makes it easier to complete cross-platform code.

In the previous article, we know that the user-state portion of the TCP/IP protocol is done by Msafd.dll, which interacts with the kernel part of the Afd.sys to implement system calls to the socket interface. Then Afd.sys completes some of the socket mechanisms and interacts with the Tcpip.sys driver to summarize the following.

1. The user-state portion of the Msafd.dll:socket interface communicates with the Afd.sys.

2. The kernel state part of the Afd.sys:socket interface, satisfies the Msafd.dll call, communicates with Tcpip.sys down.

3. The main implementation part of the TCPIP.SYS:TCP/IP protocol, satisfies the Afd.sys call, down with the small port NIC driver communicates through the IRP.

4. The socket concept is only in Msafd.dll and Afd.sys, both of which implement the socket's user-state and kernel-state portions. Their lower layers are the transport layer (TDI) layer, the TDI layer completes the TCP, UDP, RAWIP mechanism, in the TDI layer, only the address object, the Connection object, the control channel concept. The lower level of the TDI is the network layer (IP layer), in the IP layer, only the Packet concept, when the data received, through the IP packet identity, know to be submitted to TCP or UDP processing. Both the TDI layer and the IP layer are implemented by Tcpip.sys.

Knowing the concept above, there is a clearer structure, of course, the driver and device management is managed by the IO manager, but the TCPIP protocol family does not use the conventional device stack to process packets, Afd.sys and Tcpip.sys and Tcpip.sys and miniport Both drivers are implemented by sending an IRP. This also makes the implementation of the intermediate filter layer drive slightly more complex, and this is not discussed here.

So we string up the concept of the above scattered, to see the entire process from the normal socket interface to the final data from the NIC.

Socket:

Ws2_32.dll will initialize the service provider according to the registry when it loads, and the provider will inform itself of the supported address family, socket type, and protocol type. When we call the socket (af_inet, SOCK_DGRAM, IPPROT_UDP) to create a UDP type socket, depending on the parameters passed in, it will be located to the Msafd.dll service provider, and the corresponding socket creation interface will be called. It turns on the device \device\afd\endpoint, because Afd.sys creates a \DEVICE\AFD device, so a irp_mj_create IRP is sent to the Afd.sys-driven creation function, which creates a FAD_FCB struct to represent the socket, and record the next FileObject and return.

Bind:

To receive the packet, we will bind the socket to a local ip-port pair, that is, to call the bind interface, Msafd.dll will pass a control message, the second function number is Ioctl_afd_bind, and Afd.sys will then follow the above FCB The recorded device name opens the appropriate \DEVICE\UDP device and identifies the input parameter as the address of a transport layer, then Tcpip.sys creates an address object to represent the binding and, of course, assigns the appropriate port information.

Connect:

If TCP, also need to connect to the other side of the socket, similar to Bind, it will also be based on the FCB record device name to open the appropriate device, and the input parameters identified as a Connection object, Tcpip.sys will create a connection object to represent the connection.

In fact, in the TDI layer, there is a kind of called control channel, when other drivers want some information of the TDI layer, such as the current TCP or UDP connection, then it will directly open \device\tcp and other devices, because there is no incoming parameters, then Tcpip.sys will create a control channel. TDI layer The identities of these objects are stored in the corresponding fileobject->fscontext2, so that they can be differentiated later.

When the current surface preparation is done, we will look at the data receiving and sending.

SendTo:

Sent by Msafd.dll a ioctl_afd_send_datagram to Afd.sys, Afd.sys create a main function number of Irp_mj_internal_device_control, the second function number is Tdi_send_ The datagram IRP to Tcpip.sys,tcpip.sys calls the Udpsenddatagram, assembles a UDP packet, and finally passes the Ipsenddatagram to the protocol layer, which is then sent out by the corresponding small port driver.

Recvfrom:

        receiving data is slightly more complex, receiving data is sent by the Afd.sys driver a secondary function number of Tdi_receive_datagram (Afd.sys and Tcpip.sys Transport layer is the IR P_mj_internal_device_control to the TDI layer, and the TDI layer is suspended in the receive request (Datagram_receive_request) queue of the Address object in the form of receiving requests. This queue is created when the Address object is created. So when will this request be satisfied, from the network card to the data mentioned. When the network card receives the data, the protocol driver will also receive this data, in general, only the driver can handle the protocol to deal with the package, this time will proceed to the Tcpip.sys protocol part, that is, the IP protocol, Tcpip.sys according to the corresponding identity, determine the IP packet, because Tcpip.sys also completed the processing of the ARP packet, the final will be handed over to the IPV4 process, it will call Processfragment->ipdispatchprotocol, IPDISPATCHPROTOCL will distinguish what is the package, if it is The UDP packet, which calls Udpreceive, and further finds a matching address object based on the list of Address objects, Dgdeliverdata to deliver the data, which will see if there is a request in the receive request queue of the addressed object, and if not, to see if the process of receiving the data is registered. If you do not register, then you will lose this package, which is a reason for UDP unreliable.

        Then some people will have doubts, if we call after bind, we haven't had time to call Recvfrom, then, the received package is not lost, in fact, after calling Bind, will immediately send a receive request to the queue, It also avoids the occurrence of such a situation. This is only the fuse of the whole process, in Bind it is by calling Tdireceivedatagram to deliver a receive request, it will create a Tdi_receive_datagram IRP, and for this IRP Set a completion routine packetsocketrecvcomplete, Tcpip.sys responds to the IRP, inserts a request in the receive request queue for the corresponding address object, and sets the completion function for this request to Dgreceivecomplete, The user completes the function as Dispdatarequestcomplete.   When the data is delivered via Dgdeliverdata, if there is a request in the queue, the request is fulfilled, the data is copied to the buffer corresponding to the request, and when the completion function of the request is called Dgreceivecomplete, it calls the user to complete the function Dispdatarequestcomplete,diapdatarequestcomplete will complete this IRP, then the completion routine of the IRP Packetsocketrecvcomplete will be called, in Packetsocketrecvcomplete (the function in Afd.sys) to do the work first pause, back to the recvfrom call, recvfrom down to the Afd.sys layer, it will not send the IRP directly to Tcpip.sys go please In order to receive data, if there is no data in the fcb->datagramlist, it will put the Msafd.dll issued by the IRP into the fcb->pendingirplist, and hang, so the request to Tcpip.sys is the last send in Bind Send the fuse caused, back to Packetsocketrecvcomplete, it will remove an IRP from the fcb->pendingirplist and insert a packet into the fcb->datagramlist, and finally complete this IRP, then this IRP issued by Recvfrom is complete. And finally it calls Tdireceivedatagram to castPass a receive request, and then cycle through.

The approximate process of a UDP socket ends here.

Implementation of TCP/IP under Windows