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

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18239 a95241bf-73f2-0310-859d-f6bbb57e9c96

docs/develop/net/Network Stack Overview.html

@@ -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.
+	Where TCP, and IPv4 are net_protocol modules, and ARP, and the Ethernet framing are
-	All modules are connected in a chain, even though the datalink layer introduces more than
+	net_datalink_protocol modules. All modules are connected in a chain, even though the
-	one path (one for each interface).
+	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
+	protocol in the chain. The last protocol in the chain is always a domain protocol - it will
-	object will determine for which interface (which determines the datalink protocols in the
+	directly forward the buffers to the datalink module. When the buffer reaches the datalink
-	chain) the buffer is destined. The route has to be specified by the upper protocols before
+	level, an accompanied net_route object will determine for which interface (which determines
-	the buffer gets into the datalink level - if a buffer comes in without a valid route, it
+	the datalink protocols in the chain) the buffer is destined. The route has to be specified
-	is discarded.
+	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
+	protocol. The last protocol in the chain is always a domain protocol that will forward
-	that will redirect the calls to the net_datalink_protocol modules.
+	the calls to the datalink module directly, if needed.
 	</p>
 	<p>
-	The domain protocol (the net_protocol module that registered the domain, ie. IPv4,
+	A domain protocol is a net_protocol that registered a domain, ie. IPv4. Other than usual
-	but also everything that would come after it) needs to be able to execute send_data(),
+	protocols, domain protocols have some special requirements:
-	and get_route() without a pointer to its net_protocol object, as those may be called
+	<ul>
-	outside of the socket context.
+	<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
+	Similar to the need to perform send_data() outside of the socket context, all protocols
-	context, as the actual target socket is unknown during processing. Only the top-most
+	that can receive data need to handle incoming data without the socket context: incoming
-	protocol will be able to forward the packet to the target socket(s). To receive
+	data is always handled outside of the socket context, as the actual target socket
-	incoming data, a protocol must register itself as receiving protocol with the
+	is unknown during processing.
-	networking stack. The domain protocol is usually registered automatically by a
+	</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
+	The last protocol in the chain is also a special device interface bridge protocol,
-	redirects the calls to the underlying net_device.
+	that redirects the calls to the underlying net_device.
 	</p>
 	<p>
 	Incoming data is handled differently again; when you want to receive data directly