A Simple Network Driver for L4
Deluge is a basic implementation of the User Datagram Protocol as
described in [RFC768, TCP/IP]. The IP interface it sits upon (which is
hidden from the user) is somewhat broken; however it works sufficiently
well for our purposes.
As [RFC768] says, ``this protocol provides a
procedure for application programs to send messages to other programs
with a minimum of protocol mechanism. The protocol is transaction
oriented, and delivery and duplicate protection are not guaranteed.
Applications requiring ordered reliable delivery of streams of data
should use the Transmission Control Protocol (TCP).''
[RFC768] also dictates the desired protocol; we
have tried to temper the semantics given with the semantics of the L4
serial driver[L4REF]. Thus, we have changed the
receive operation to be analogous to the input function of the serial
driver. The interface is summarised in ipdriver.h.
UDP consists of datagrams (packets) sent from a port
on one host to a port on another host. Host IP addresses can be stored
in a 32-bit unsigned int; port numbers range from 0-65535 and can be
stored in a 16-bit unsigned int. Good port numbers to use are in the
1024-4096 range; if you do
netstat -a on a box you can see
which ports are already in use. High port numbers can only be used by
recompiling the stack on the U4600 (which currently supports up to 4096
only). Ports below 1024 are reserved for use by root.
UDP is unreliable: packets can get lost, or arrive out of order. In
addition, you are not guaranteed to be able to send more than 512
bytes; thus, you should limit your packet size to 512 bytes or
less, like a good protocol (eg DNS, TFTP, etc (-: ).
All messages are sent in either a short IPC or a long IPC with exactly
one string dope:
All other fields in the register portion are described below.
- The first dword in the register portion of the IPC
contains the message type (either UDP_BIND or
- The second word contains the local port's address (high 32-bit
word: IP address, low 32-bit word: port number).
- The third word contains a size descriptor of some sort (either
packet size, or maximum message size information).
In general, all control information is sent in the register portion of
the IPC; the long portion consists of a single string dope referring to
a buffer of a pre-agreed length. In the initial handshaking, both
server and client specify the string dope length they are willing to
accept. Currently, the server will accept outgoing packets of up to
1kb and its incoming packets can be up to 1kb in size. These limits
can be changed at compile-time, however increasing them may reveal bugs.
Note: The driver expects the PCI to be
little-endian. Make sure your clock driver is little-endian as
well, or you'll have problems!
A bind request (which performs the same as a
socket()/bind() in the traditional Berkeley interface) has four
parameters in a short IPC:
- Request type (UDP_BIND),
- Local address (port number to bind to),
- Maximum message size (maximum incoming packet size),
- Handler thread (where the packets should be sent to).
The return IPC is identical, except that the from address now has the
main interface's IP address in the top 32-bit word, and the ``maximum
message size'' is the size of the string that the server will listen
The short portion of the IPC contains the following:
- Request type (UDP_PACKET),
- Local address (port number to bind to; IP address section
- Message size (size of packet in octets),
- Remote address (high word: IP, low word: port).
The long portion is a single string; its length should be the length
returned in the bind call.
The bind call registers a listener thread which should be prepared to
receive long messages consisting of a single string (of the same
length that it registered with). Upon receipt of a packet, the server
will send a long IPC with a short timeout; if the receiver is not
ready, the packet is dropped (silently).
The message is sent in the same format as described above (in sending
Note that the thread which sends the data received from the
network is different from the thread to which bind requests and data
packets are to be sent.
- Jon Postel. RFC 768: User Datagram Protocol. ISI,
- Richard Stevens. TCP/IP Illustrated, Volume 1.
Addison-Wesley, Reading, MA, USA, 1994.
- Kevin Elphinstone, Gernot Heiser,
Jochen Liedtke. L4 Reference
Manual, MIPS R4x00. UNSW, 1997.
School of Computer Science and Engineering,
University of New South Wales
This page is maintained by
Last modified: Wednesday, 16-Aug-2000 12:01:01 AEST