OSDev.org

Hi,

I'm a little confused how everything connects together in a netstack. Like between apps, the netstack, and drivers.

Does the netstack consist of two parts? An interface for apps to do read() & write()? And would this be exposed through VFS? Or a separate networking library? And would this call into the netstack for writing, and have a callback to notify it that data is available? So basically a sockets lib?

And then the other part being the netstack itself? This would interact only with the drivers & the user level sockets(?) library?

Some clarification here would be great =)

Jonathan

Does the netstack consist of two parts? An interface for apps to do read() & write()? And would this be exposed through VFS? Or a separate networking library? And would this call into the netstack for writing, and have a callback to notify it that data is available? So basically a sockets lib?

Under Linux (and *BSD) AFAIK, the network stack is seperated from the other IO-drivers (for storage and all the other io-stuff) and has nothing to do with the VFS. Instead they provide a seperate set of system calls which just deal with network interfaces. The user application only deals with establishing socket connections, and reading/writing from/to these.

But that doesn't mean that you can't go a different way . Nothing prevents you from implementing the network stack as some kind of 'pseudo device', which offers functionality to establish socket connections, which the applications can use to transfer data to remote hosts. In fact, it's up to you.

I think beyond infinity knows more details about the internals of a network stack, I'm still far away from this topic. ::)

cheers Joe

The network stack is the best possible example that "everything is a file" assumption doesn't hold everywhere. Okay, network sockets (once communication is established) somehow look like a file ...

somehow ...

if you can think that a file could close itself spontaneously or that it could prevent you to seek it ...

btw, other parts such as network devices are certainly not files and do not even appear anywhere in the VFS (e.g. you have /dev/hdd, but nothing like /dev/eth0 or /dev/eth0/ip/tcp/localport80/ ...)

Pype.Clicker wrote: if you can think that a file could close itself spontaneously or that it could prevent you to seek it ...

Well, you can't seek a serial port either, as well as a FIFO. Anyway, they are presented as files by unix-like systems. Don't get me wrong, I'm not at all a friend of the 'everything is a file'-concept. IMO, as soon as you need an ioctl, your device doesn't behave like a file anymore. But that's all just a matter of design...

btw, other parts such as network devices are certainly not files and do not even appear anywhere in the VFS (e.g. you have /dev/hdd, but nothing like /dev/eth0 or /dev/eth0/ip/tcp/localport80/ ...)

In current unix-like OSs, no, as I stated. But if you say that your system represents devices as files, it could still be helpful to give network cards at least a name in the filesystem so that they can be identified like any other device. Of course you can't read/write them like files, so interaction with them would be limited to ioctls.

cheers Joe

I daresay, it's as easy as keep a socket subsystem, separated from the file system. I don't want to have my vfs munched with network stuff.

as for network stack - possible architecture:

socket layer (where all begins & ends) -> tcp/udp/icmp layer -> ip layer ->ethernet layer.

this goes in both directions.

Mark: connection oriented protocols tend to deal out quite a lot of events which may affect the corresp. socket. So it's good to incorporate callbacks into the socket layer, which the tcp layer f. ex. can call, if a remote close comes along; say, you have callbacks for open_socket, close_socket,rcvfrom,sendto,accept ... this way you can deal with events the easiest way.

MarkII: even your network stack is to be organized like an event oriented thing - like your kernel.

Mark III: keep your ip frags & your tcp segs sorted (it's required by the protocol anyway).

mark IV: decide upon some kind of network buffer structure - where you keep a chain of buffers (like blocks in a File System) and can append or remove header stuff or already-read-data or already-ack'd-data.

Hope this Helps. I can't write precisely now --- 've had maths test today. Complex numbers. Proof by induction to n. Differentiating.

As conjecture (not having implemented a network stack as yet), it would be plausible to implement file based networking.

Something along the lines of:
/dev/netstack/ip/
- tcp
* outgoing
* incoming
- udp
* outgoing
* incoming

A program could establish a connection using:Opening the file in the outgoing virtual directory tells the netstack to establish a connection to the given IP:Port, if it fails then it returns a NULL FILE* and an error code. "rb+" is the only supported open method (simultaneous read/write).

The file read/write operations take the place of the socket send/recv functions. In the event of a broken connection, the connection file is removed and the state of the FILE*s would be set to a broken/bad state (causing all further read/writes to fail).

The incoming directory could work similarly using: /dev/netstack/ip/tcp/incoming/80. A program would use a 'directory watch' API to open the port and wait for an incoming connection, the connection would appear as IP:SourcePort as per before which can then be opened for read/write.

In all cases, closing the file representing the connection will disconnect the "peer". The peer would be rejected automatically if no program is watching that particular port and the connection would timeout if it isn't accepted in an open port as usual.

Of course, this shouldn't be taken as an indication that this is actually a good idea...

AR wrote:
Of course, this shouldn't be taken as an indication that this is actually a good idea...

i have to say, realy interesting and good idea

purevoid wrote: I'm a little confused how everything connects together in a netstack. Like between apps, the netstack, and drivers.

It might not be quite what you were asking, but if you haven't seen it already, the OSI model is a good way to sort out at least where the different interconnections can be in a network stack:

http://en.wikipedia.org/wiki/OSI_reference_model

It's totally abstract, so it won't tell you how to implement the connections between different layers, but can give some ideas on where to put a different layer. Keep in mind that it's pretty rare that every layer is implemented seperately; It's quite normal to merge a two or more of them (especially at the higher levels).

Myself, i'm in the middle of an IPv4 implementation myself, but i'm trying to avoid typical POSIX/Un*x ways of doing things as much as possible, so i'm not using a Berkley sockets type model, but just running it over my existing IPC. Networking has more in common with IPC than files anyhow IMHO.

HTH