Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

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.

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 .

Sorry to break up the funny train, but TCP acts just like a normal person in this scenario:
1) TCP orders a beer
2) Bartender acknowledges the order and serves up a beer
3) TCP acknowledges receipt of the beer by paying for it.
No silly "shaking hands 3 times" nonsense, just sensible interaction.

I think the problem is that you fail to recognize a 3-way handshake when you see it. Like, the one I just described for you (SYN, SYN-ACK, ACK). You also seem to confuse "a 3-way handshake" with "shaking hands 3 times" (i.e. a series of 3 2-way handshakes). You were programming network drivers, and you don't understand something this simple? Scary.

No I'm not failing to recognize it or whatever. How do you do 3 way handshaking without actually making somekind of interaction between customer and bartender (which customer starts) three times?

But now when I'm giving it more serious thought it could go like customer shakes hand with bartender and says "hi", bartender answers "hi", customer says "okay" or something like that to end the handshaking and starts Beer Ordering Procedure. In T/TCP "okay" could contain also the order if I remember correctly.

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.

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.

It is true that in some situations, it can be better to convert critical software elements over to hardware for a better experience. They tried that with Java though, and it didn't seem to work.. wait, are you talking about something else?

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.

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.

yeah, but learning how to write device drivers for Minix is a pretty useless skill.

What? As long as you learn the concepts you will do just fine. And Minix is a fine example of how to study the principles and concepts of operating system design. Once you understand the basics you can go ahead and get your feet dirty in Linux, Solaris, Mac OS, Windows, whatever you like.

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.

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.

Even if I accept your conclusion, which I don't, the lovely thing about open source is that you can add your own protocols and interfaces as you please. Obviously, only something really amazing has a chance to survive, but it was ever thus in the jungle.