Network handling

[Jeko]

I've find some documents about network handling, but they don't talk of network handling, but of network cards driver developing.

How do you handle network devices in your kernel? And what about network stacks?

[01000101]

The normal way of getting network operations up and running is to create a network driver, and then abstract some network protocol functions that the driver (and other net drivers) may use.

If you do not provide that abstraction for the network stack and functions, you would have to re-implement those in every network driver that you code.

[Jeko]

The normal way of getting network operations up and running is to create a network driver, and then abstract some network protocol functions that the driver (and other net drivers) may use.

If you do not provide that abstraction for the network stack and functions, you would have to re-implement those in every network driver that you code.

Yes, I know, network drivers will be kernel-mode drivers. There will be a function to transmit and a function to receive data. The interface is simple, only transmit and receive.

But, for network stacks? Are they drivers? Or are they handled in user-mode?

EDIT: I think network card drivers will only transmit and receive data in a RAW way. Network stacks will abstract network card drivers. They will use network card drivers functions to handle network protocols. For example ARP -> IP -> ETH -> RTL8139.
But will network stacks (I mean ARP, IP, ETH) be drivers?
And what about TCP, UDP, etc.?

[Jeko]

Are there anyone that has network handling in his kernel? How do you handle network?

[pcmattman]

I'm currently writing a network stack, so I thought I'd help out

Basically, it is literally a stack (diagram is an example):

Code: Select all

TCP, UDP
------------------------------
IP
------------------------------
Ethernet (link layer)

I've greatly simplified this for purposes of explanation. The link layer is the level at which packets are sent and received on the network (ARP and some other protocols work over this layer).

To send data over UDP (I'm not going to use TCP as an example because it's far more complicated), data to send has a UDP header prepended to it. It is then moved down the stack to IP, where a IP header is prepended to it. Finally, it's moved to the link layer, where the Ethernet header is prepended and it's dispatched to the network device.

To receive a UDP datagram, the network driver passes a received packet to the link layer (typically via something like 'eth_recv'). The link layer inspects the packet, finds that it's an IP packet and so sends it up the stack to the IP layer (typically something like 'ip_recv'). The IP layer looks around, does some checks, and then passes it up to the UDP layer ('udp_recv' ). Once here, the packet is inspected (source and destination ports) and finally passed on to whatever place it needs to go. Typically you'd put the received datagrams onto some form of queue created when a process binds to an address, but that's up to you.

If you have any questions I'd be more than happy to help you out, it's not always easy to figure this stuff out.

[Jeko]

I'm currently writing a network stack, so I thought I'd help out

Basically, it is literally a stack (diagram is an example):

Code: Select all

TCP, UDP
------------------------------
IP
------------------------------
Ethernet (link layer)

I've greatly simplified this for purposes of explanation. The link layer is the level at which packets are sent and received on the network (ARP and some other protocols work over this layer).

To send data over UDP (I'm not going to use TCP as an example because it's far more complicated), data to send has a UDP header prepended to it. It is then moved down the stack to IP, where a IP header is prepended to it. Finally, it's moved to the link layer, where the Ethernet header is prepended and it's dispatched to the network device.

To receive a UDP datagram, the network driver passes a received packet to the link layer (typically via something like 'eth_recv'). The link layer inspects the packet, finds that it's an IP packet and so sends it up the stack to the IP layer (typically something like 'ip_recv'). The IP layer looks around, does some checks, and then passes it up to the UDP layer ('udp_recv' ). Once here, the packet is inspected (source and destination ports) and finally passed on to whatever place it needs to go. Typically you'd put the received datagrams onto some form of queue created when a process binds to an address, but that's up to you.

If you have any questions I'd be more than happy to help you out, it's not always easy to figure this stuff out.

Thank you for your explaination.
But I need to know how to implement layers. For example in your os, what is UDP? Is it a driver? Or is it a process? Or what else?
I need a generic network handling structure, because I will handle all type of protocols. I think in my OS all these layers will be drivers. But I don't know, maybe there are methods better than mine.

However, thank you, your informations will be very useful when I'll write network drivers!

[pcmattman]

In my implementation it's all built into the operating system. This of course means you can't install a custom network stack later on (and updates to it require a kernel update), but it also makes it very simple to visualise the interface between each layer.

If you did use a driver interface, it is a bit harder but not exceptionally difficult. I've not done it before myself but I do have books here that talk about such a method. In these you would have a "device" for each layer of the stack. "recv" pushes a packet up a layer, and "send" pushes a packet down a layer - or for a more POSIX-like approach you could use "write" and "read".

The trouble is when you hit an endpoint where you actually want to push a packet to a user application. There are many ways to do this, and for purposes of example I'm going to use UDP.

Say a UDP packet comes in with destination port 12345. It's gone through each driver until the IP driver finally pushes it to the UDP receiver. This function looks around and realises that there's a socket waiting for data on port 12345 (you could do this with a structure called a PCB - protocol control block - which stores information relating to connections in the system). By using some form of IPC (or another method) the incoming datagram is pushed onto a receive queue for that application's socket. When the application next calls read on the socket, you look to that receive queue and pick up the earliest datagram - and the application has received data!

You just turn it around to send data. Put data on a send queue or similar, and then the send call on the socket will handle passing it down the layers.

This is of course a very basic example and isn't necessarily all correct, I've just thrown it all together to give an example of what you can do.

[bewing]

In my OS, I'm implementing "stacks" as a pipeline of drivers.

[Dex]

In my OS i have a full TCP/IP stack that comes with the ethernet card driver, therse two together are only about 9Kin size, so when the driver is loaded, it hooks into some interrupts, if you call the int and 0 is returned then no driver is loaded, or else you have full set of socket functions through the int's

[Jeko]

How do you handle the presence of two (or more) network cards?

[pcmattman]

Every one of my handler functions takes an extra parameter (I call it "iface") that indicates the interface to use in the system. 0 would be the first ethernet device, 1 the second, and so on.

This only really works as the entire stack is implemented in the kernel though.

[Jeko]

Every one of my handler functions takes an extra parameter (I call it "iface") that indicates the interface to use in the system. 0 would be the first ethernet device, 1 the second, and so on.

This only really works as the entire stack is implemented in the kernel though.

I thought I can implement something like this:
NETCARD0 NETCARD1
- -
- -
ETH0 ETH1
- -
- -
IP0 IP1
- -
- -
TCP0 TCP1
UDP0 TCP1

So the "device" TCP1 will use IP1 and ETH1 and NETCARD1 (It is possible also that TCP1 uses IP0 and TCP2 uses IP1, it depends on the user configuration).

But this is really confusing. I need a clear design, that can be simply configured by the user, but I don't know how to handle it...

If a user applications opens a socket, for example TCP, how the TCP can know which is its lower layer? It can be IP, but also something else... And how can IP know which is its lower layer? It can be Ethernet, but also something else...

Do you have some document about network handling?

[pcmattman]

It's hard to call because I have reference books on the subject, but nothing I can provide via the internet.

The book I use the most as a reference is the second volume of the XINU "Operating System Design" books by Douglas Comer. While it is quite old everything is still highly relevant and the protocols haven't changed much since its publishing date. The theory is very easy to understand (the code's another story altogether).

A suggestion of what you could do is have each upper layer "linked" to another layer. This has a few complications when you think about how to implement it though

[djsilence]

Hi!

You know, I'm really know anything about network support in own OS. There is only one I know: The number of IRQ's - 16. Right? Then wat a **** is an IRQ22 (Network driverer source in Windows) and etc. (like IRQ17 - for SoundCard)??

Sorry, if I'm wrong.

Daniel.

[JackScott]

Using the newer APIC-based interrupt system, I believe the number of hardware interrupts is much higher. I haven't checked though. OSDev wiki will have more information.