When sending data through a socket, a net_buffer is created in the socket module, and passed on to the lower levels where each protocol processes it, before passing it on to the next - protocol in the chain. When the buffer reaches the datalink level, an accompanied net_route - object will determine for which interface (which determines the datalink protocols in the - chain) the buffer is destined. The route has to be specified by the upper protocols before - the buffer gets into the datalink level - if a buffer comes in without a valid route, it - is discarded. + protocol in the chain. The last protocol in the chain is always a domain protocol - it will + directly forward the buffers to the datalink module. When the buffer reaches the datalink + level, an accompanied net_route object will determine for which interface (which determines + the datalink protocols in the chain) the buffer is destined. The route has to be specified + by the upper protocols before the buffer gets into the datalink level - if a buffer comes + in without a valid route, it is discarded.
The protocol modules are loaded and unloaded as needed. The stack itself stays loaded @@ -134,21 +135,29 @@
The protocols are bound to a specific socket, process the outgoing buffers as needed (ie. add or remove headers, compute checksums, ...), and pass it on to the next - protocol. The last protocol in the chain is always a special datalink bridge protocol - that will redirect the calls to the net_datalink_protocol modules. + protocol. The last protocol in the chain is always a domain protocol that will forward + the calls to the datalink module directly, if needed.
- The domain protocol (the net_protocol module that registered the domain, ie. IPv4, - but also everything that would come after it) needs to be able to execute send_data(), - and get_route() without a pointer to its net_protocol object, as those may be called - outside of the socket context. + A domain protocol is a net_protocol that registered a domain, ie. IPv4. Other than usual + protocols, domain protocols have some special requirements: +
- This is similar for incoming data, which is always handled outside of the socket - context, as the actual target socket is unknown during processing. Only the top-most - protocol will be able to forward the packet to the target socket(s). To receive - incoming data, a protocol must register itself as receiving protocol with the - networking stack. The domain protocol is usually registered automatically by a + Similar to the need to perform send_data() outside of the socket context, all protocols + that can receive data need to handle incoming data without the socket context: incoming + data is always handled outside of the socket context, as the actual target socket + is unknown during processing. +
++ Only the top-most protocol will be able to forward the packet to the target socket(s). + To receive incoming data, a protocol must register itself as receiving protocol with + the networking stack. The domain protocol is usually registered automatically by a net_datalink_protocol module that knows about both ends (for example, the ARP module is both IPv4 and ethernet specific, and therefore registers the AF_INET domain to receive ethernet packets of type IP). @@ -163,8 +172,8 @@ ethernet header, etc.
- The last protocol in the chain is also a device interface bridge protocol, that - redirects the calls to the underlying net_device. + The last protocol in the chain is also a special device interface bridge protocol, + that redirects the calls to the underlying net_device.
Incoming data is handled differently again; when you want to receive data directly