Interprocess Communication & Sockets

Protocols and the TCP/IP Stack

The problem. Two programs running on two different computers cannot read each other's variables: each has its own private memory. If they are to cooperate, one must put data into a message, hand it to the network, and the other must pick it up. Interprocess communication (IPC) is the name for how processes on different computers exchange data in this way.

IPC is the foundation for everything higher up in the subject. Remote method invocation (Part VI), group communication and publish-subscribe (Part VII), the NFS file system (Part VIII) and DNS (Part IX) are all built from the primitives in this Part: UDP and TCP sockets, marshalling, multicast and overlays. The picture shows where those primitives sit.

Clients, servers and protocols exam

Client-server computing has three elements. A client is a process that requests a service. A server is a process that offers a service to one or more clients. The two are joined by a network. (A process is simply a running program.)

For the two to understand each other, sending bytes is not enough: they must agree in advance on what the bytes mean and when to send them. That agreement is a protocol.

Humans follow protocols too, but theirs are unspoken (eye contact, gestures, taking turns to talk). Computers need the rules spelled out exactly. Because an agreed protocol says nothing about the programming language or the machine, a Java program can talk to a C program as long as both follow it.

The course example is Buyya's Math server. It reads one line of text of the form operator:first:second, such as +:12:21, and replies with one line holding the answer.

The TCP/IP stack exam

Sockets, the programming interface this Part teaches, live inside the TCP/IP protocol stack, so it helps to know what each layer does. A layer is a piece of networking software that offers a service to the layer above and uses the service of the layer below. The four layers, from the top down, are:

Encapsulation: how data moves through the stack

Data moves through the stack by encapsulation. On the way down, each layer wraps what it was given in its own header (a block of control information such as addresses) and passes the bigger package down. On the way up at the receiver, each layer reads and strips off its own header and passes the rest up. Step through it:

Best effort: what IP does not promise

The Internet layer is unreliable, or "best-effort": it tries to deliver each packet but promises nothing. IP packets may be lost, duplicated, delayed or reordered. IP also checksums only its own header, not the data, so TCP and UDP add their own checksums. (A checksum is a small number computed from the bytes; the receiver recomputes it, and a mismatch reveals corruption.) Putting the check at the ends rather than in the network is the end-to-end argument from Part II at work.

Addresses

Hosts are identified by IP addresses. An IPv4 address is 4 bytes, written in "dotted-quad" form, one decimal number per byte, such as 128.250.25.158. An IPv6 address is 16 bytes. People use host names instead, and DNS (Part IX) maps a name to its address.

TCP vs UDP exam

The transport layer offers applications two protocols that make very different promises. Choosing between them, and being able to list their differences, is one of the most reliably examined skills in the subject: the 2016 exam asked for three differences outright.

Connection-oriented means the two ends must first set up a connection, an agreed two-way channel, before any data flows. Connectionless means each datagram is sent on its own, carrying its full destination address, with no set-up.

How TCP builds reliability on top of unreliable IP

Since IP is only best-effort, TCP has to manufacture its guarantees out of extra machinery at the two ends (CDK §3.4.6). There are six mechanisms:

• Connection set-up. The two ends agree a bidirectional channel before data flows. The routers in between know nothing about it: the connection exists only as state at the two ends.
• Sequence numbers. Each segment carries the byte offset of its data within the stream, so the receiver can put segments back in order and drop duplicates.
• Acknowledgements and retransmission. The receiver acknowledges ("acks") the data it has received; if no ack arrives before a timeout, the sender retransmits.
• Flow control. Acks carry a window size: how much the sender may send before the next ack. A slow reader can therefore throttle a fast writer.
• Receive buffering. Incoming data is held in a buffer at the receiving end until the application reads it.
• Checksums cover both the header and the data.

UDP, by contrast, adds very little to IP: only ports, a length field and an optional checksum. There is no set-up and there are no acks, and a single message can be up to 64 KB. The header layouts show the difference in how much each protocol carries.

The comparison table exam

Be able to reproduce most rows of this table. An exam answer that names the dimension ("Connection: …", "Reliability: …") and then states both sides is the easiest way to collect every mark.

Why not use TCP for everything?

Because guaranteed delivery costs three overheads (CDK §4.2.3):

1. State has to be stored at both the source and the destination (sequence numbers, buffers, timers).
2. Extra messages have to be transmitted (the set-up handshake and the acks).
3. The sender suffers extra latency (it must wait for the set-up before sending, and for acks).

Choosing between them

Ports and Sockets

The problem. An IP address only gets data as far as the right computer. But one computer runs many processes at once (a web server, a mail server, your browser), so something else has to pick out the right process. That is the job of ports. Sockets are then what those processes actually program against.

Ports exam

Well-known ports and port ranges

Some services have well-known ports, registered with IANA (the body that assigns Internet numbers), so that every client knows where to find them:

Who owns a port

The rules on ownership come from CDK §4.2.2. A port has exactly one receiving process but can have many senders; IP multicast (3.9) is the one exception. A process may use several ports, but processes cannot share a port, so a second attempt to bind one fails with BindException. A client's port is chosen by the system, whereas servers publicise their port numbers so that clients can reach them.

Location transparency: don't hard-code the address

Hard-coding (IP, port) into a client pins the service to one machine forever. To get location transparency (clients not needing to know where a service physically is), clients instead ask a name server or binder (Part VI, Part IX) for the service by name at runtime. This allows relocation of a service (moving it between runs and re-registering), but not migration while it is running.

Sockets exam

Sockets come from BSD UNIX, and they are the programming interface at the transport layer. They are language-independent, so a socket program in Java can talk to one written in C. The picture is the one to carry in your head: a socket is a process's "doorway" onto the network, and its address is an IP address plus a port.

"A socket handle is treated like a file handle"

Socket I/O follows the same pattern as file I/O: you open the socket, read and write through streams, then close it. getInputStream() and getOutputStream() return ordinary Java streams, so the same wrapper classes you use for files work on sockets unchanged.

The listen/accept model (TCP) exam

How can one TCP server talk to many clients at once, all on the same well-known port? The answer is that the server uses one socket only for listening, and gets a brand-new socket for every client it accepts:

1. The server binds a listening socket to its well-known port and listens.
2. The client creates a socket, to which the system assigns a port, and sends a connection request to (server host, port).
3. The server accepts the request. This creates a new socket dedicated to that client, and all further communication with the client goes through it.
4. The original listening socket stays open, so the server can accept other clients while it serves this one.
5. Requests that have not yet been accepted wait in the listening socket's queue. Java's default queue length is 50, and a request that arrives when the queue is full is refused.

TCP Sockets in Java

Now the ideas become code. The java.net package gives you a handful of classes, and the TCP server and client each follow a short fixed recipe. This is the code the exam expects you to be able to read, explain and write.

The java.net classes

The java.net package has one class for IP addresses, two for TCP and three for UDP:

• InetAddress represents an IP address and hides whether it is IPv4 or IPv6. getByName("host") does a DNS lookup and can throw UnknownHostException.
• ServerSocket is the TCP server socket. new ServerSocket(port) binds and listens; port 0 means any free port, which you can read back with getLocalPort(). accept() blocks (the calling thread waits) until a request arrives, and then returns a Socket.
• Socket is one end of a TCP connection. new Socket(host, port) creates the socket and connects it. Its main methods are getInputStream(), getOutputStream(), setSoTimeout() and close().
• DatagramSocket is a UDP socket. A server constructs it with a port, and a client with none, which gives it any free port. It offers send(), a blocking receive(), setSoTimeout() and connect().
• DatagramPacket holds one datagram: the message bytes, their length, and a host and port. There is one constructor for sending and another for receiving, and the accessors are getData(), getLength(), getAddress() and getPort().
• MulticastSocket is a subclass of DatagramSocket that adds joinGroup(), leaveGroup() and setTimeToLive().

Stream wrappers (java.io)

A socket's streams only move raw bytes. To send typed values or lines of text, you wrap them in whichever java.io class suits your protocol, exactly as you would a file stream:

• DataOutputStream and DataInputStream write and read primitive values (writeInt, writeUTF, …) in a machine-independent binary format, which makes them a simple external data representation (3.8).
• For line-based text protocols, use BufferedReader.readLine() together with PrintWriter or BufferedWriter. The slides' DataInputStream.readLine() is deprecated.
• ObjectOutputStream and ObjectInputStream send whole objects (3.8).

Be careful with writeUTF: it sends a 2-byte length followed by the UTF-8 bytes of the string, so every writeUTF must be matched by a readUTF.

Exceptions: each failure has a name

All of these are subclasses of IOException, so a single catch (IOException e) catches them all, but knowing which is which tells you what went wrong.

The TCP recipes exam

The client

The client below follows the four steps, and its comments mark each one. It sends the string "hello" and prints what comes back.

// TCPClient.java - send a string, print the reply
import java.net.*;
import java.io.*;

public class TCPClient {
    public static void main(String[] args) {
        try (Socket s = new Socket("localhost", 7896)) {                  // 1. connect
            DataInputStream in = new DataInputStream(s.getInputStream());     // 2. streams
            DataOutputStream out = new DataOutputStream(s.getOutputStream());
            out.writeUTF("hello");                                       // 3. send
            System.out.println("Received: " + in.readUTF());             //    receive
        } catch (UnknownHostException e) {
            System.out.println("Unknown host: " + e.getMessage());
        } catch (IOException e) {                    // e.g. ConnectException if server not up
            System.out.println("IO: " + e.getMessage());
        }                                            // 4. try-with-resources closes the socket
    }
}

The server, and why it uses threads

A server must serve many clients. The slides' recipe for that is a while(true) loop that accepts a client and then creates a thread, passing it the client socket as a parameter. (A thread is an independent line of execution inside a process; Part IV covers them fully.) The thread creates the streams, serves the client, and ends when it is done. This design is called thread-per-connection (CDK Fig. 4.6).

The contrast is an iterative server, such as the slides' SimpleServerLoop, which does the same work in the main thread. While it is blocked serving one slow client, it cannot accept() anyone else.

// TCPServer.java - echo server, one thread per connection
import java.net.*;
import java.io.*;

public class TCPServer {
    public static void main(String[] args) throws IOException {
        ServerSocket listenSocket = new ServerSocket(7896);       // 1. open server socket
        while (true) {
            Socket clientSocket = listenSocket.accept();          // 2. wait for a client
            new Thread(new Connection(clientSocket)).start();     // hand it to a worker thread
        }
    }
}

class Connection implements Runnable {
    private final Socket socket;
    Connection(Socket socket) { this.socket = socket; }

    public void run() {
        try (Socket s = socket;                                    // 5. closed automatically
             DataInputStream in = new DataInputStream(s.getInputStream());      // 3. streams
             DataOutputStream out = new DataOutputStream(s.getOutputStream())) {
            while (true) {
                String data = in.readUTF();    // 4. blocks THIS thread only
                out.writeUTF(data);            //    echo
            }
        } catch (EOFException e) {             // client closed its end
            System.out.println("Client left");
        } catch (IOException e) {
            System.out.println("IO: " + e.getMessage());
        }
    }
}

Run the two programs against each other and this is the order in which the calls happen:

Message framing over TCP exam

The problem. TCP delivers a byte stream with no message boundaries. TCP itself decides how to cut the data into segments, and a read returns whatever bytes have arrived so far. So one write may arrive split over several reads, which is called a partial read, and, conversely, several writes may arrive together in one read.

The fix. The application protocol must frame each message so that the receiver knows where it ends. There are three ways:

What goes wrong without framing. A message that is cut in two fails to parse, or a reader blocks forever waiting for data that the writer thinks it has already sent. This is the "matching of data items" issue of 3.7. The snippet shows the delimiter approach, with one JSON object per line.

// Line-framed JSON (also import java.nio.charset.StandardCharsets)
BufferedReader in = new BufferedReader(
        new InputStreamReader(s.getInputStream(), StandardCharsets.UTF_8));
PrintWriter out = new PrintWriter(
        new OutputStreamWriter(s.getOutputStream(), StandardCharsets.UTF_8), true); // autoflush
out.println("{\"op\": \"QUERY\", \"subjectCode\": \"COMP90015\"}"); // one object + '\n'
String reply = in.readLine();  // collects partial reads until '\n'; null means peer closed

• InputStreamReader(…, UTF_8) turns bytes into characters using an explicit encoding, and BufferedReader adds readLine().
• PrintWriter(…, true): the true turns on autoflush, so every println is sent immediately.
• out.println(…) writes one JSON object followed by the '\n' delimiter.
• in.readLine() keeps collecting partial reads until it sees '\n', then returns the whole line; it returns null when the peer has closed the connection.

UDP Sockets in Java

With UDP there is no connection to set up, so the code deals only with sockets and packets. That makes it shorter than the TCP code, but it also means the program itself has to cope with whatever the network does: nothing tells you a datagram went missing.

A process creates a DatagramSocket. A server binds it to its agreed port, while a client lets the system pick any free port. To send, you build a DatagramPacket(bytes, length, address, port) and call send(): no connection is needed, because every packet carries its own destination. To receive, you pass in an empty DatagramPacket(buffer, buffer.length), and receive() fills in the data, its length and the sender's address and port. That last part is how the receiver knows where to send a reply.

The client sends one datagram and waits for an answer; the server echoes each datagram back to whoever sent it.

// UDPClient.java - send one datagram and wait up to 2 s for the reply
import java.net.*;
import java.io.*;

public class UDPClient {
    public static void main(String[] args) {                 // args: message, server host
        try (DatagramSocket socket = new DatagramSocket()) {   // any free local port
            byte[] m = args[0].getBytes();
            InetAddress host = InetAddress.getByName(args[1]);
            socket.send(new DatagramPacket(m, m.length, host, 6789));
            DatagramPacket reply = new DatagramPacket(new byte[1000], 1000);
            socket.setSoTimeout(2000);                         // don't block forever
            socket.receive(reply);
            System.out.println(new String(reply.getData(), 0, reply.getLength()));
        } catch (SocketTimeoutException e) {
            System.out.println("Timeout: request/reply lost or server down");
        } catch (IOException e) {
            System.out.println("IO: " + e.getMessage());
        }
    }
}

// UDPServer.java - echo each datagram back to its sender
import java.net.*;
import java.io.*;

public class UDPServer {
    public static void main(String[] args) {
        try (DatagramSocket socket = new DatagramSocket(6789)) {   // agreed server port
            byte[] buffer = new byte[1000];
            while (true) {
                DatagramPacket request = new DatagramPacket(buffer, buffer.length);
                socket.receive(request);                           // from ANY sender
                socket.send(new DatagramPacket(request.getData(), request.getLength(),
                        request.getAddress(), request.getPort()));  // reply to sender
            }
        } catch (IOException e) {
            System.out.println("IO: " + e.getMessage());
        }
    }
}

Three pitfalls in the slide and textbook versions

• Use m.length, which counts bytes, rather than the string's length(), which counts characters. The two differ for non-ASCII text (an accented letter is two bytes in UTF-8).
• Print only getLength() bytes of the buffer, because otherwise stale buffer contents are printed too.
• A message larger than the buffer is silently truncated:

Characteristics of IPC exam

This section steps back from code to the general vocabulary CDK (§4.2.1) uses to describe any message-passing IPC. The same words (synchronous, blocking, reliable, ordered) come back in RPC, group communication and every later topic, so they are worth getting exactly right.

Message passing uses two operations, send and receive, defined in terms of a message (a sequence of bytes) and a destination. Each destination has a queue: senders add messages to it, and the receiver removes them.

Synchronous vs asynchronous; blocking vs non-blocking

An operation is blocking if the calling process (or thread) is suspended until something happens; non-blocking if it returns at once. The main distinction is between synchronous and asynchronous communication, and the table shows what each means for the two operations. Notice that only the asynchronous send is non-blocking, while receive is usually blocking either way.

In practice: Java's UDP has a non-blocking send and a blocking receive. With TCP, a read blocks until data arrives, and a write can block under flow control (when the receiver's buffer is full).

Destinations, reliability and ordering

Message destinations are (IP address, local port) pairs, with one receiver per port (3.3). The other two characteristics describe what the service promises about delivery.

Reliability, in CDK's sense, is validity plus integrity (the failure model of Part II). Keep these three words: the failure models in 3.7 are stated in exactly these terms.

UDP and TCP: Issues and Failure Models exam

CDK now looks at each protocol in turn through the lens of 3.6: what issues a programmer must handle, and what can go wrong (its failure model, the precise list of failures it can suffer). These lists are frequently examined, and the TCP one contains the subject's favourite trick question: "is TCP reliable?"

UDP datagram communication (CDK §4.2.3)

A datagram is sent without acknowledgements or retries. There are four issues to know when using UDP:

UDP's failure model

• Integrity: UDP's checksum makes corruption negligible, but there is no duplicate detection.
• Omission failures: messages are dropped because of checksum errors or a lack of buffer space at the source or destination.
• Ordering failures: messages can be delivered out of sender order.

Applications therefore add their own checks: acknowledgements, retransmission and duplicate filtering turn UDP into a reliable request-reply protocol, which is exactly what Part VI builds. Uses: UDP suits DNS and VoIP, where occasional loss is acceptable, and more generally any application that wants to avoid the three overheads of guaranteed delivery.

TCP stream communication (CDK §4.2.4)

TCP takes the opposite approach: it presents the application with a stream and hides the awkward properties of the network underneath. There are five network characteristics the stream abstraction hides:

Roles, streams and closing

The client creates a socket and connects; the server's listening socket holds a queue of requests and accepts them. After set-up, the two can act as peers: each socket has an input stream and an output stream. Closing a socket means "I will write no more": data already buffered is still delivered, and once the reader has consumed it, further reads report end of stream (EOFException, -1, or null, depending on the read method). Using a broken stream gives an IOException.

Three issues when using TCP streams

• Matching of data items. The two sides must agree on the content and order of what is sent. If one writes an int then a double, the other must read an int then a double; otherwise the data is misinterpreted or the reader blocks. Framing (3.4) is part of this agreement.
• Blocking. Reads block when no data is queued, and writes block under flow control.
• Threads. A server typically creates one thread per accepted connection, so that blocking on one client doesn't delay the others. Without threads, UNIX select can test which streams have input ready.

TCP's failure model: is TCP reliable?

TCP protects integrity with checksums and sequence numbers, and validity with timeouts and retransmission. Even so, TCP is still not fully reliable. With excessive loss, a severed network or heavy congestion, TCP eventually declares the connection broken. When that happens, the processes cannot distinguish a network failure from a crash of the remote process, and they cannot tell whether their recent messages were received.

The two gold boxes are identical, and that is the point: from the client's side the two cases look exactly the same, and in neither can it know whether its last messages got through. Uses: TCP carries HTTP, FTP, Telnet and SMTP, each on a reserved port.

Marshalling and External Data Representation exam

The problem. Inside a program, data lives in structures: records, arrays, objects pointing at other objects. A network carries only a flat sequence of bytes. So before sending, the data must be flattened into bytes, and on arrival it must be rebuilt. The complication is that machines differ in how they lay data out in memory:

• byte order: big-endian machines store the most significant byte of a number first, little-endian machines the least significant byte first;
• floating-point formats;
• character codes: ASCII (one byte per character) versus Unicode.

There are two ways to cope with these differences:

The table compares the four representations covered below. The rows on type information and marshalling code are the ones that separate CDR from Java serialization most sharply.

To make the comparison concrete, the rest of this section encodes the same record in each format: a person called Smith, from London, born in 1984.

CORBA Common Data Representation (CDR)

CORBA is a multi-language middleware; IDL (Interface Definition Language) is the language-neutral notation in which both sides declare their data types. CDR has 15 primitive types, including short (16-bit), long (32-bit), their unsigned variants, float, double, char, boolean, octet (a raw byte) and any. Two rules govern how values are laid out:

• Byte order: values are sent in the sender's byte order, which is flagged in the message, and the receiver converts only if its own order differs (approach 2 above).
• Alignment: a primitive of n bytes starts at an index that is a multiple of n.

Constructed types are built from the primitives:

No type information is sent. Both sides know the types from the IDL definition, and the IDL compiler generates the marshalling code. (Sun XDR, used by NFS, works similarly but always uses big-endian.) Step through the marshalling of struct Person {string name; string place; unsigned long year;} holding {"Smith", "London", 1984}, laid out 4 bytes per row:

0-3   5        length of "Smith"
4-7   "Smit"
8-11  "h___"   padded with zeros to a 4-byte boundary
12-15 6        length of "London"
16-19 "Lond"
20-23 "on__"
24-27 1984     unsigned long

Java object serialization

Java takes the opposite approach to CDR and sends type information along with the data. Serialization flattens an object, or a connected set of objects, for storage or transmission (for example as RMI arguments, Part VI), and deserialization restores them. A class allows this by declaring implements Serializable, a marker interface: one with no methods, which only labels the class as serializable.

The receiver is assumed to have no prior knowledge of the types, so the stream carries class information: the class name and a version number (serialVersionUID, or a hash of the class definition). The receiver uses it to check that it has the correct version of the class.

The whole object graph is serialized. If the object refers to other objects, those are serialized too. References are written as handles (small numbers standing for an object already in the stream), and each object and class is written only once; any later occurrence just uses the handle. This is what preserves shared references and cycles.

transient marks fields that must not be serialized, such as references to local resources like files and sockets, which mean nothing on another machine.

Reflection is what makes serialization generic. It is the ability of a program to inspect a class's name and its fields' names, types and values at runtime. So no per-class marshalling code is needed, unlike in CORBA. Deserialization uses it too: it loads the class by name, creates a constructor and fills in the field values.

public class Person implements java.io.Serializable {
    private String name, place;
    private int year;
    private transient java.net.Socket conn;          // not serialized: local resource
}
// sender: new ObjectOutputStream(sock.getOutputStream()).writeObject(person);
// receiver: Person p = (Person) new ObjectInputStream(sock.getInputStream()).readObject();

• implements java.io.Serializable: permission to serialize; nothing to implement.
• name, place, year: ordinary fields, serialized with their names and types.
• transient … conn: skipped; after deserialization it is null.
• writeObject(person) marshals the whole graph onto the socket's stream; readObject() rebuilds it and returns an Object, hence the cast (Person).

XML and JSON

The two text formats encode the same record as readable characters. (The guide's version also includes an id.)

<person id="123456789">
    <name>Smith</name>
    <place>London</place>
    <year>1984</year>
</person>

{"id": 123456789, "name": "Smith", "place": "London", "year": 1984}

XML in more detail

XML (a W3C standard) is a textual, self-describing markup language. Its tags describe the data's structure, not its appearance, which is what distinguishes it from HTML. It is also extensible: users define their own tags, although applications that share documents must agree on them, as with SOAP's published tags.

• Building blocks: elements, which nest and so can represent hierarchies, and attributes, which are labels for simple values. Any binary data is encoded as base64 (binary turned into text characters).
• Well formed: tags match and are correctly nested, and there is a single root element.
• Namespaces (xmlns:pers="URL") scope tag names to avoid clashes between vocabularies.
• A schema defines the allowed elements and attributes, their nesting, order and types, so that a document can be validated. DTDs are an older, weaker way of doing this.

XML vs JSON trade-offs exam

Each format has advantages over the other, and you should be able to argue both directions.

The two also have a lot in common: both are textual, human-readable and language-independent, and both are larger and slower than binary formats such as CDR or serialization. The tutors' point-by-point comparison is in 3.11.

Remote object references (CDK §4.3.4)

Marshalling also has to cope with references to objects in other processes. A remote object reference is "an identifier for a remote object that is valid throughout a distributed system". It is placed in invocation messages to say which object is to be invoked (Part VI).

Multicast Communication exam

Everything so far has been one process talking to one other. But some jobs need one process to talk to many: telling every replica of a database about an update, say. Sending a separate copy to each would be slow and would require knowing every member. Multicast solves this: it is sending one message from one process to every member of a group of processes, usually with group membership transparent to the sender.

Multicast has four uses:

IP multicast

In IP multicast, the sender transmits one IP packet to a multicast group, which is identified by a class D address: one whose first bits are 1110. The sender does not know who the members are or how big the group is. Membership is dynamic, so hosts can join and leave at any time, and you can send to a group without being a member.

For applications, IP multicast is available only through UDP. A socket joins the group, and every local socket that has joined and is bound to the destination port receives a copy, which makes this the one case where several processes share a port. Between networks, multicast routers forward the packets, and the TTL ("time to live") limits how many routers a packet may cross; Java's default of 1 keeps it on the local network.

IP multicast's failure model exam

IP multicast has the same failure model as UDP: omission failures, which makes it unreliable multicast. A message may reach some members but not others. That can be caused by loss between routers (which affects every member beyond that router), by a recipient's buffer being full, or by a multicast router failing. There is also no ordering: one sender's messages can arrive in different orders at different members, and messages from different senders arrive in different orders too.

How much this matters depends on the use. Replicated services need every replica to receive every request, and in the same order, or the replicas diverge, whereas discovery can tolerate loss. Hence the need for stronger protocols, built in Part VII:

• reliable multicast: a message is delivered to all members or none;
• totally ordered multicast: all members see all messages in the same order.

Multicast in Java

MulticastSocket s = new MulticastSocket(6789);          // UDP socket on port 6789
InetAddress group = InetAddress.getByName("228.5.6.7"); // class D group address
s.joinGroup(group);                                     // now receives group traffic
s.send(new DatagramPacket(m, m.length, group, 6789));   // one send reaches all members
s.receive(packet);                                      // own and peers' messages
s.leaveGroup(group);  s.close();

Overlay Networks and MPI

The last two topics are brief in the guide (CDK §4.5 and §4.6), but both appear in the self-test, and the overlay flooding problem is modelled on a real 2016 exam question. Overlays answer the question "how do I get a network service the Internet doesn't provide, without changing the Internet?"; MPI answers "what does message passing look like when performance is everything?"

Overlay networks

Overlays come in three types, grouped by what they are for:

Case study: Skype

Skype is built on an overlay. Its super nodes are ordinary hosts chosen for their bandwidth, reachability (a global IP address, not hidden behind NAT, the address translation home routers do) and availability. Users log in through a central login server, searches for users run across the super nodes, and a call needs no IP address or port. For the calls themselves, TCP is used for call signalling and UDP is preferred for media, with TCP, possibly through a relay node, used to get through firewalls.

Broadcast over an overlay of servers: flooding exam

In flooding, each server forwards a message to all its neighbours except the one it came from. This is safe only if the server graph is a tree (a connected graph with no loops). If a new server can connect to several existing servers, the graph has cycles, so copies circulate forever and members receive duplicates.

MPI: the Message Passing Interface

MPI is a standard, from the MPI Forum in 1994, for message passing in high-performance computing (large parallel computations on clusters). It is portable, independent of the operating system and of language-specific socket APIs, and it has over 115 operations.

Its model is send and receive plus MPI library buffers at both ends. In MPI, blocking means "blocked until it is safe to return", that is, until the application's own buffer can be reused without corrupting the message.

There are four kinds of send, each in a blocking and a non-blocking form. The non-blocking forms return a handle at once, which you check later with MPI_Wait or MPI_Test.

The receives are MPI_Recv (blocking) and MPI_Irecv (non-blocking), and they combine freely with any send. In this way MPI separates the synchronous/asynchronous distinction from the blocking/non-blocking one, which 3.6 treated as linked. MPI also has collective operations, which include scatter (split data among processes) and gather (collect it back).

Pitfalls and Tutorials 2 & 4

This last section gathers the mistakes that lose marks, a design question that pulls the whole Part together, and the official tutor answers from Tutorial 2 (Week 3: sockets, UDP and TCP) and Tutorial 4 (Week 5: data representation). Staff have confirmed the tutorial answers are examinable.

Common pitfalls

Putting it together: a design question

Tutorial 2 (Week 3): sockets, UDP and TCP official answers

The tutors' summary of UDP versus TCP matches 3.2. UDP is the simplest connectionless IPC: it offers a message-passing abstraction and sends single datagrams, and it is used for real-time video streaming, DNS and NTP. TCP offers a two-way stream with no message boundaries. It is the basis for producer/consumer communication, in which data is queued until the consumer is ready and the consumer waits when no data is available. It is used for HTTP and FTP.

Tutorial 4 (Week 5): data representation, XML and JSON official answers

The marshalling material repeats 3.8, including the two approaches: convert to an agreed external format, or send in the sender's format with an indication of which format it is. The tutors' XML vs JSON comparison, though, adds points to the trade-offs in 3.8. The table lines the two formats up point by point: