Spectranet: Tutorial 1

Tutorial 1: A High Level View

The Spectranet is more than just an ethernet MAC/PHY that plugs into the back of a Spectrum - it also contains support hardware to interact properly with the machine, and also a software library to allow the programmer to write network programs pretty much in the same way as with any other computer. This sequence of tutorials is to get a programmer started writing networked programs. The knowledge is portable to other systems, too - so you're not just learning about having fun with the Spectrum, the information here will come in useful for most other situations where you might want to write network code!

The Spectranet comprises of the following 'layers':

• Physical: The W5100 chip, which contains a PHY (physical layer) interface, the MAC (media access control) and an IP offload engine. In turn, this is interfaced to...
• The CPLD: A modern day ULA. This intercepts calls that are for the Spectranet and controls the paging of the memory (flash ROM, static RAM and W5100 network buffers), which in turn is controlled by...
• The socket library and associated code. The socket library, and a number of other useful functions, lives in the Spectranet's flash ROM.

The Spectranet exposes its library as a set of indirect calls (don't worry about this too much yet). The indirect call interface, which is defined in spectranet.asm (a file assembly language programmers will need), provides the public interface. (The indirect call table is actually stored in RAM, so the programmer can override it and extend it, without having to modify programs that use it). The C socket library is a lightweight wrapper around these calls, to translate the C calling convention (passing parameters on the stack) into the relevant registers. When using assembly language, you call the routines directly via the table. This will become clear in the following tutorials.

Protocols

The Spectranet's socket library supports sockets for two IP protocols at present - TCP and UDP. These are by far the most commonly used - virtually every networked program that a user directly interacts with ultimately uses either TCP or UDP. A brief description:

• TCP - or the Transmission Control Protocol, is used where a reliable stream is needed. Think of TCP as if it were a short serial lead to another computer - anything you put down the wire will arrive in the same order it's sent, and it will arrive (unless someone pulls the plug). Some examples of programs that use TCP: a web browser, an IRC client, an ftp program, some network filesystems, and ssh (secure shell). It's a complex protocol designed to cope with network congestion, packets arriving out of order, duplicate packets, dropped packets etc. in such a way the programmer doesn't need to worry about these things. You could describe TCP as being "chuntey free".
• UDP - or the User Datagram Protocol. With UDP, you do not have a stream, what you have is a socket where you can send datagrams - short messages. They aren't guaranteed to arrive, and a sequence of datagrams is not guaranteed to arrive at the remote host in the same order that they are sent. Examples of programs that use UDP are DNS resolvers, voice over IP programs, multi user games, some network filesystems, and DHCP clients. The stateless nature of UDP allows the programmer to decide the way of dealing with network issues that is best for the application.

When you write a networked program, you have to decide (if you're writing the whole thing from scratch - existing protocols will already determine whether you're going to use TCP or UDP!) which of these you're going to use. Generally, if you're going to write a networked game, or anything where a delayed or misordered message may as well be discarded, you'll use UDP. Anything where you don't want to necessarily keep connection state, you'll want to use UDP. However, if you need to send or receive data that resembles a stream that must be kept in order, then you'll want to use TCP. You may have noticed 'some network filesystems' was mentioned both under 'TCP' and 'UDP'. Some network filesystems have their own method of dealing with dropped and misordered packets that are optimized for the filesystem in question and use UDP. Others just leave it up to the underlying protocol - and use TCP.

There's also the issue of resources: with the Spectranet hardware, you can communicate with a maximum of four remote hosts using TCP, but with UDP, you can communicate with as many hosts as you have resources to keep track of them all.

If you want to really get to grips with the differences between TCP and UDP, here are two links that will get you started, on Wikipedia:

• TCP - Everything you wanted to know about TCP, and were afraid to ask. The first section, 'Reason for TCP' is a succinct explanation of why you would want to use it.
• UDP - A detailed article on the user datagram protocol, including the differences compared to TCP.

Next: Spectranet: Tutorial 2 - A simple TCP based server.