Haiku/haiku
Haiku/haiku
1
0
Fork 0
mirror of https://review.haiku-os.org/haiku synced 2025-01-31 02:35:03 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Reworked the parts that are affected by the reintroduction of the datalink module.

Browse Source 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18239 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Axel Dörfler 2006-07-21 09:48:33 +00:00
parent 7e24384c6e
commit cd1e67ac69
1 changed files with 30 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
docs/develop/net/Network Stack Overview.html
View File

@ -34,18 +34,19 @@
<tr><td bgcolor="#ffee88">Ethernet framing</td></tr>
<tr><td bgcolor="#ffdd00">Ethernet device</td><td bgcolor="#ffdd55"><font size="-2">(physical layer)</font></tr>
</table>
Where TCP, and IPv4 are net_protocol modules, and ARP, and the Ethernet framing are net_datalink_protocol modules.
All modules are connected in a chain, even though the datalink layer introduces more than
one path (one for each interface).
Where TCP, and IPv4 are net_protocol modules, and ARP, and the Ethernet framing are
net_datalink_protocol modules. All modules are connected in a chain, even though the
datalink layer introduces more than one path (one for each interface).
</p>
<p>
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.
</p>
<p>
The protocol modules are loaded and unloaded as needed. The stack itself stays loaded
@ -134,21 +135,29 @@
<p>
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.
</p>
<p>
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:
<ul>
<li>they need to be able to execute send_data(), and get_domain() without a pointer to
its net_protocol object, as those may be called outside of the socket context.</li>
<li>as mentioned, they also don't talk to the next protocol in the chain (as they are
always the last one), but to the datalink module directly.</li>
</ul>
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
Incoming data is handled differently again; when you want to receive data directly