Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!tardis.computer-science.edinburgh.ac.uk!alnitak From: alnitak@tardis.computer-science.edinburgh.ac.uk Newsgroups: comp.os.minix Subject: Minix TCP/IP Message-ID: Date: 2 May 90 15:00:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 99 [Originally a reply to a message I received in response to my previous posting Re: TCP/IP and Minix] The idea I have for the Minix TCP/IP implementation is to have the TCP/IP handler run as one module on the same layer as the MM and FS. This would allow any BSD type system calls (ie `socket', `accept', and even `read' and `write') to run as Minix system calls. The `read' and `write' calls I would either trap in the FS and send to the IP module, or modify the library calls to do the trapping (ie check in read.c and write.c if the file handle is for a socket, and if so send the message to the IP module instead of the FS). This allows compatibility with currently available socket based code, so the extra effort involved with this probably far outweighs (IMHO) the effort required to re-write/modify existing clients and servers. I do not know yet how I would actually handle the sockets as far as the FS is concerned. They could take the form of either pure entities in memory, or a variation on the named pipe. I really haven't studied the original code enough to see how feasible this is. I don't know if anyone out there has studied the Sun Networking Guide, but that shows all of the data structures and protocol layers that are used in the Sun TCP/IP implementation. Their version is based on the OSI communications model. This also shows useful things like the use of system IOCTL calls to alter the SunOS kernels copy of the kernel routing table. If anyone ones to learn how a fairly good networking system is implemented, take a look at this book. At the moment, I see all of my networking code (apart from the actual device I/O) happening in the IP module, which would be a single executable. I hope to make this code completely machine independent so that the only dependencies will be in the device drivers, which should normally exist in the kernel anyway. Obviously with the 64k I & D restriction on MINIX/PC there may be some coding problems in keeping the software small enough, but I would like to think that this won't be a problem. I feel that it is important that IP packets should be capable of using any bidirectional communications device on the system, hence the IP module would find from the routing table which I/O device a particular packet must go through in order to reach its destination, then call a routine which will append or prepend any extra information needed for the device (ie, nothing for Ethernet devices, start of packet' and `end of packet' blocks for Serial Line IP, etc.). This is because the vast majority of Minix users will not be able to afford or connect to an ethernet system, and may well end up relying on a SLIP connection to any other hosts. Hence the overall model that I am currently working on is: Revised Figure 2.26, Page 87 [AST] +--------+-----------------------------------+ 4 | INIT | Application layer | +--------+-----+--------------+--------------+ 3 | FS | MM | IP | +--------------+--------------+--------------+ 2 | Disk | TTY | Clock | System | .... | +--------+-------+---------+----------+------+ 1 | Process Management | +--------------------------------------------+ Layout of IP module +--------------------------------------------+ 4 | Socket Handler | +-------+-------+----------------------------+ 3 | TCP | UDP | ........................ | +-------+-------+----------------------------+ 2 | IP / Router | +---------+--------+-------------------------+ 1 | ETHER | SLIP | ..................... | +---------+--------+-------------------------+ The socket handler determines which Protocol Module to send the data within the packet to (eg TCP or UDP). The Protocol Module then passes the packet on to the IP Module. When an IP packet is to be sent out, it is first passed to the Router which figures out which I/O device the packet is to be sent to, and then calls the relevant output routine. The output routine for that device appends and prepends any extra info (see above). The packet is then finally passed to the output device using normal `read' and `write' calls to the relevant device from /dev. In this way minimal (or even non-existant) changes need to be made to the MM, FS and Kernel, and machince dependancy is minimised (I would hope that no changes at all would need to be made to the Kernel, as this is the only one of the three layers which is machine dependent. Any additional device drivers here would be needed in order to use that device anyway). Hope this all makes sense... Ray Bellis p.s. Please, please, please, let's have any comments on this, good or bad, I don't care. I really do think that Minix warrents having a properly written version of TCP/IP written from scratch, rather than hacked together from somebody elses code for a different O.S. ------------------------------------------------------------------------------ Ray Bellis: Janet (UK): alnitak@uk.ac.ed.cs.tardis & u87rpb@uk.ac.oxford.ecs Elsewhere: alnitak@tardis.cs.ed.ac.uk ------------------------------------------------------------------------------