COMP30023 · Computer Systems
Sockets, DNS and Mail
Week 7 covers application/transport programming: the Berkeley socket API and the client-server call sequence used in the projects, DNS name resolution and the latency it adds, and email as a store-and-forward push protocol (SMTP) with pull-based access (POP3/IMAP). Ordering the socket calls, explaining connection identity via the 5-tuple, and describing DNS resolution up the hierarchy are common exam questions.
What this chapter covers
- 01Sockets as the doorway between application (user space) and transport (kernel space); the file-descriptor abstraction
- 02The socket 5-tuple (protocol, local IP, local port, remote IP, remote port); listening sockets as 3-tuple half-sockets
- 03Server call sequence socket → bind → listen → accept, and client sequence socket → connect; which calls block
- 04Blocking vs non-blocking reads: a read() may return fewer bytes than a write() sent; loop until 0
- 05DNS: mapping domain names to IP addresses at the application layer; the four elements (name space, database, name servers, resolvers)
- 06Resource-record types (A, AAAA, MX, NS, CNAME, PTR, SOA, TXT); zones and authoritative servers
- 07Resolving a query up the hierarchy (local DNS → root → TLD → authoritative) and the role of caching
- 08Email: user agents and message transfer agents; SMTP push (port 25, store-and-forward) vs POP3/IMAP pull access
Ordering the TCP socket calls for a server and a client
- +1Server sequence: socket() creates the endpoint → bind() attaches a specific local IP and port → listen() announces willingness to accept and sets the backlog queue → accept() waits for a connection → then read()/write() exchange data → close().
- +1Client sequence: socket() creates the endpoint → connect() actively establishes the connection to the server's IP and port → write()/read() exchange data → close().
- +1(a) accept() is the call that blocks: it sleeps until an incoming connection request arrives, then returns a brand-new connected socket for that client.
- +1(b) The server ends up with two sockets because the listening socket is a 3-tuple 'half socket' (protocol, local IP, local port) that acts like a receptionist and only accepts connections, while each accept() returns a distinct connection socket that is a full 5-tuple (protocol, local IP, local port, remote IP, remote port) used to actually read from and write to that one client. One listening socket can spawn many connection sockets.
Key terms
- Socket
- The endpoint through which an application sends and receives over the network — the doorway between user-space application code and kernel-space transport code. In UNIX it is addressed by an integer file descriptor, so it is read and written like a file.
- Socket 5-tuple
- The full identity of a connection: (protocol, local IP, local port, remote IP, remote port). A TCP listening socket and most UDP sockets are only a 3-tuple (protocol, local IP, local port) — a 'half socket' — until a connection fills in the remote endpoint.
- bind / listen / accept / connect
- The core TCP socket calls: bind attaches a local address; listen announces willingness and sets the backlog; accept blocks until a client connects and returns a new connection socket (all passive/server); connect actively establishes a connection (client). accept and connect deal with full sockets; bind and listen work on the half socket.
- DNS (Domain Name System)
- An application-layer system mapping human-readable domain names to IP addresses via a distributed hierarchy of name servers holding resource records. Resolvers query up the hierarchy (local → root → TLD → authoritative), and caching speeds repeated lookups.
- Resource record (RR)
- A named piece of DNS data. Common types: A (IPv4 address), AAAA (IPv6 address), MX (mail exchanger), NS (name server), CNAME (alias), PTR (reverse lookup), SOA (zone parameters), TXT (text/SPF).
- SMTP (Simple Mail Transfer Protocol)
- The push-based, store-and-forward mail-transfer protocol over TCP (default port 25). Mail hops through message transfer agents, each storing then forwarding the whole message; recipients then pull mail with POP3 or IMAP (or HTTP web mail).
Sockets, DNS and Mail FAQ
What is the correct order of socket calls for a TCP server and client?
Server: socket() → bind() → listen() → accept() → read()/write() → close(). Client: socket() → connect() → write()/read() → close(). The server calls bind (to claim a port), listen (to set up the accept queue) and accept (to wait for and pick up a connection); accept is the call that blocks until a client arrives. The client just creates a socket and connects. Getting listen and accept in the right order, and knowing accept blocks, are frequent single-mark points.
What identifies a TCP connection, and can one port serve many connections?
A connection is identified by the full 5-tuple: protocol, local IP, local port, remote IP, remote port. Between one fixed (local IP, local port) and one fixed (remote IP, remote port) there can be only one connection. But a single local port (say a web server on port 80) can serve enormous numbers of simultaneous connections, because each differs in the remote IP and/or remote port. That is why a server's listening socket is a 3-tuple but each accepted connection is a full 5-tuple.
How does DNS resolve a name to an IP address?
A resolver asks its local DNS server. If that server has the answer cached it returns it; otherwise it queries up the hierarchy — a root server, then the relevant top-level-domain server, then the authoritative server for the domain — and relays the answer back, caching it for next time. DNS runs at the application layer, so it must itself use a socket (to a hard-coded name-server IP), and each lookup adds latency, which is why caching matters for performance.
Why is SMTP described as store-and-forward, and how is mail delivered?
Because a message does not travel end-to-end in one hop: it passes through message transfer agents, each of which stores the entire message and then forwards it toward the destination (SMTP over TCP, port 25, push-based). The final recipient does not receive a push; they pull their mail from their server using an access protocol — POP3 (download, often delete) or IMAP (keeps state and folders on the server), or HTTP web mail. So sending is push, final access is pull.
Can AI help me with sockets and DNS in COMP30023?
Yes, as a study aid. Sia can quiz you on the socket call order and the 3-tuple/5-tuple identity, walk through DNS resolution up the hierarchy, or explain SMTP store-and-forward step by step, and it can help you reason about the socket logic in the C projects without writing the graded code for you. It supports learning the method; it does not do your graded exam, quizzes or projects, and University of Melbourne academic-integrity rules apply.
Exam move
Week 7 is doubly important because it is examined in the final and it directly underpins the C socket-programming projects that feed the coursework hurdle, so invest here early. Memorise the server and client call sequences and be able to say which calls are passive vs active and which one blocks, plus the 3-tuple-vs-5-tuple identity and why one port serves many connections. For DNS, learn the four elements, the common resource-record types, and the resolution walk up the hierarchy with caching; for mail, keep the SMTP-push / POP3-IMAP-pull and store-and-forward story straight. Rehearse these as short boxed answers and reason about the read()-may-return-fewer-bytes gotcha you will hit in the projects. Confirm project deadlines and the exam date on Canvas so the projects never collide with revision, protecting both the hurdle and your WAM.
Working through Sockets, DNS and Mail in COMP30023? Sia is AskSia’s AI Computer Science tutor — ask any COMP30023 Sockets, DNS and Mail question and get a clear, step-by-step explanation grounded in how COMP30023 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
