The Linux Networking Stack Exposed

An anonymous reader writes "The Linux source code is a great way to learn about the design of device drivers for a multitude of device types, including network device drivers. This article will show you the basic architecture of the Linux networking stack and dig into its interfaces for system calls, protocols, and device drivers."

well

I doubt we're going to see any +5 funny mods in this one

Re:well

I doubt we're going to see any +5 funny mods in this one

Oh yeah?

So, a UDP connection walks into a bar and it goes up to the bartender.

"Hi bartender, " it says to the bartender.

"Howdy, UDP connection. What'll it be?" the bartender asks.

"I'll have a beer please. Here's a dollar," says the UDP connection.

The bartender takes the dollar, looks at the UDP connection, and continues wiping glasses.

"So, what'll it be?" the bartender asks the UDP connection.

The UDP connection forks over another dollar and orders a beer again. The bartender takes the dollar and stares expectantly at the UDP connection as he continues to wipe glasses.

"So, what are you gonna drink, little UDP connection?" the bartender asks.

"I would like a beer please," and the UDP connection gives the bartender yet another dollar. The bartender takes the dollar and promptly starts wiping the counter. He looks thatthe UDP connection and asks,

"Oh, hello there. Can I get you anything?"

"Yes please," responds the UDP connection, "I'd like a beer. Here is a dollar." And the UDP connection gives the bartender yet another dollar.

And so on...

Re:well

And when TCP walks into the bar and asks for beer bartender opens the tap and lets beer stream... But before that they have to shake hands three times.

Re:well

it would be more like :

TCP : Can i get a beer ?
Bartender : You asked for a beer ?
TCP : Yes i did .
Bartender : Ok , here's the beer , that will be ...
TCP : did you just tell me how much to pay you ?
Bartender : yes i did .
TCP : ok , here's ...

and say the bartender has bad hearing ;

TCP : Can i get a beer ?
Bartender : You asked for a lemonade ?
TCP : no i didn't .
TCP : Can i get a beer ?
Bartender : Ok , here's the beer , that will be ...
TCP : did you just tell me how much to pay you ?
Bartender : yes i did .
TCP : ok , here's ...

TCP constantly verifies that the data was received , while udp only verifies that the data was correct . udp would end up with a lemonade , drink it , and just order a beer again .

Re:well

Oh yeah?

So, a UDP connection walks into a bar and it goes up to the bartender.

"Hi bartender, " it says to the bartender.

"Howdy, UDP connection. What'll it be?" the bartender asks.

"I'll have a beer please. Here's a dollar," says the UDP connection.

The bartender takes the dollar, looks at the UDP connection, and continues wiping glasses.

"So, what'll it be?" the bartender asks the UDP connection.

The UDP connection forks over another dollar and orders a beer again. The bartender takes the dollar and stares expectantly at the UDP connection as he continues to wipe glasses.

"So, what are you gonna drink, little UDP connection?" the bartender asks.

"I would like a beer please," and the UDP connection gives the bartender yet another dollar. The bartender takes the dollar and promptly starts wiping the counter. He looks thatthe UDP connection and asks,

"Oh, hello there. Can I get you anything?"

"Yes please," responds the UDP connection, "I'd like a beer. Here is a dollar." And the UDP connection gives the bartender yet another dollar.

And so on...

[Memento joke here]

So I guess writing stuff down on it's arms would turn the UDP connection into a TFTP session.

Where's the NetBIOS?

How come I don't see any references to NetBIOS in the stack?

Expose it, babe!

Woo! Show us your bits!! [linux.no]

What about Minix?

Personally I'd say Minix is much easier to navigate, simpler to understand and a much better starting point for new kernel developers or students to begin with (it was designed primarily as an academic project).

I've tried digging around the Linux source code, but find a lot of it fairly confusing simply because of the amount of time and effort you have to invest in understanding the rest of it and general architecture.

With Minix, you can pretty much jump in at any place (being very organized and well separated you can find what you're looking for fast), in 3.0 the core syscalls are separated into different files and the core kernel is only around 5000 lines which you can scan through fairly quickly.

Re:What about Minix?

Personally I'd say Minix is much easier to navigate, simpler to understand and a much better starting point for new kernel developers

Perhaps you should send a link to the kernel devs and suggest they emulate it...

Beg to differ

IMHO the networking stack is quite uninteresting. On the bottom, it's constrained by the networking protocols and network interfaces. On the top it's constrained by the Unix and socket interfaces. That doesnt leave a whole lot of room for innovative bits in the middle.

Re:Beg to differ

IMHO the networking stack is quite uninteresting. On the bottom, it's constrained by the networking protocols and network interfaces.

Yes, the Linux network stack has always been constrained by the fact that it has to handle networking.

I contributed a series of highly innovative patches that added 3D Graphics and AJAX support to the Linux TCP/IP stack. Were those kernel developers interested? Were they fuck.

Just another reason why Linux will continue to lag behind Windows and OSX in the innovation stakes.

Broken link

The imbedded link is broken. Try here instead: http://www.ibm.com/developerworks/linux/library/l- linux-networking-stack/ [ibm.com]

When I saw this headline....

.... I became so excited I nearly had a buffer overflow!

Need som real info?

Seems like both the TCP/IP bible and the TCP/IP packet layout is missing from this article, so here it is:
1. the book: TCP/IP Illustrated, Volume 1 by W. Richard Stevens
2.
from netinet/ip.h /* Per RFC 791 */
struct ip {
        uint8_t ip_hl:4, /* header length */
                        ip_v:4; /* version */
        uint8_t ip_tos; /* type of service */
        uint16_t ip_len; /* total length */
        uint16_t ip_id; /* identification */
        uint16_t ip_off; /* fragment offset field */
        uint8_t ip_ttl; /* time to live */
        uint8_t ip_p; /* protocol */
        uint16_t ip_sum; /* checksum */
        struct in_addr ip_src,ip_dst; /* source and dest address */
};

from netinet/tcp.h: /* Per RFC 793 */
struct tcphdr {
        uint16_t th_sport; /* source port */
        uint16_t th_dport; /* destination port */
        tcp_seq th_seq; /* sequence number */
        tcp_seq th_ack; /* acknowledgement number */
        uint8_t th_x2:4, /* (unused) */
                        th_off:4; /* data offset */
        uint8_t th_flags;
        uint16_t th_win; /* window */
        uint16_t th_sum; /* checksum */
        uint16_t th_urp; /* urgent pointer */
};

Better unexpose the stack code....

... or SCO might find some "new and improved" infringements on the Unix rights they don't own.

SCO: How do we get our hands on the code for Linux?
Lawyer: Pay me $$$ and I will get the courts to order it handed over.
SCO: You are such a bargain!

I want those

15 seconds back.

Re:OOOOhhh

My server is like a beautiful exotic woman. She ignores the obvious attempts to get close to her, but if you know the right ports, she opens up. Of course, she encourages security and doesn't allow unprotected remote ehm...administration.