Exam practice

An IP address only gets data to the right computer. A computer runs many programs that use the network, and the port number says which program the data is for: on one server, 443 for the web server, 22 for SSH, 25 for email.
A web server must listen on a port every client already knows, so it uses the well-known port for HTTPS, 443; a browser never has to be told. A client is never contacted first, so any free port will do: the operating system lends it a temporary one for each connection, which also makes each connection’s four numbers (both addresses, both ports) different, so two tabs on the same website are kept apart.

The segments are 801–1800, 1801–2800 and 2801–3800. An acknowledgment names the next byte wanted.

1. Segment 801–1800 arrives → ACK 1801.
2. Segment 1801–2800 is lost.
3. Segment 2801–3800 arrives early: kept → ACK 1801 again (still waiting for 1801).
4. No acknowledgment of 1801 comes before the sender’s timer runs out → segment 1801–2800 is sent again.
5. It arrives; the receiver now has 801–3800 → ACK 3801.

The program at the receiving end gets all 3,000 bytes, in order, after step 5.

• i.TCP: every byte of the file must arrive, or it is spoiled; a little delay doesn’t matter.
• ii.UDP: a piece of picture that arrives late is useless; it is better to carry on without it than to freeze.
• iii.UDP: the question and answer are tiny, and if either is lost the client simply asks again, with no handshake to wait for.

The telephone network used circuit switching: before a call, a path through the exchanges was set up and reserved for that call until it ended. The internet uses packet switching: nothing is reserved; data goes in packets, each routed on its own, and every link carries everyone’s packets in turn. The telephone network kept its cleverness in the exchanges; the internet keeps it in the computers at the ends (the end-to-end principle).
Advantages: links are shared and used fully, with no capacity wasted on silences; if a router or link fails, packets go round it; new uses (the web, video calls) can be invented at the ends without changing the network.
Disadvantage: nothing is guaranteed, so when links are busy, packets are delayed or lost (which TCP has to repair, and which spoils live calls).

• a.To replace notice 12 with the data sent (PUT: put this at that address).
• b.{"title": "Football match moved to Friday"}, in JSON, as the Content-Type header says.
• c.HTTP remembers nothing between requests, so the browser sends the session cookie with every request; the server looks it up to know who is asking.
• d.200 OK (or 204 No Content) if it works; 404 Not Found if there is no notice 12; 403 Forbidden for a signed-in student who isn’t allowed (401 would mean not signed in at all).

A certificate contains the names it is for (such as bhakaripay.com.np), the site’s public key, the dates it is valid from and to, who issued it, and that issuer’s digital signature over all of it.
The browser checks that: (1) the signatures lead, through any intermediates, to a root certificate authority in its own trusted list; (2) the certificate is for the very name in the address bar; (3) today is between its dates (and it hasn’t been withdrawn).
A valid certificate doesn’t prove that the site is honest or safe: anyone can buy a lookalike name, such as bhakaripay-reward.com, and get a valid certificate for it. It proves only that you reached the owner of the name in the address bar.

JSON: {"district": "Ilam", "tea": true, "elevation_m": [500, 3600], "notes": null}
Read back with json.loads(): "Ilam" a string; true → True; [500, 3600] → a list [500, 3600], not a tuple (JSON has no tuples); null → None. So the dictionary that comes back isn’t equal to the original, because of the tuple.

The server trusts a price the client sent. The browser belongs to the user: anyone can change the page’s JavaScript in the developer tools, or send their own POST request with "price": 1, and the server would charge Rs 1.
Fix: the client sends only what the customer chose ({"item": "school bag", "quantity": 1}); the server looks up the price in its own database and works out the total itself. The page may still show a total, for the customer’s convenience, but the server’s total is the one charged.

The diagram should show: students’ phones (hardware) running a browser with the notices page (HTML, CSS, JavaScript); the internet (routers, DNS); a server computer in a data center or at the school (hardware) running an operating system, a web server program (HTTPS) and the app’s program (for example Python); and a database with the notices table, on the server’s disk. Links: HTTPS on port 443 between the phones and the web server; SQL between the app’s program and the database. A teacher’s laptop may be drawn too, as another client.
The check “only teachers may post notices” must run on the server, in the app’s program, on every request that posts a notice (by the session cookie: whose session is it, and is that person a teacher?). The page may hide the Post button from students, but anyone can send a POST request without the page, so only a check on the server protects the notices.

Without a timeout, a client waits for ever for a server that will never answer, and the user sees a frozen app. A well-written client gives up after a set time (say 10 seconds), tells the user plainly that the server couldn’t be reached, and lets them try again (or tries again itself after a pause).

• 200: use the data.
• 400: the request was wrong: read the error message and fix what is sent (often, tell the user what to correct).
• 401: sign in first (or the session has run out), then try again.
• 404: there is nothing at that address: check the address or the id; don’t retry the same request.
• 429: too many requests: wait (the server may say how long) and send fewer.
• 503: the server is busy or down for now: try the same request again later, waiting a little longer each time.

• a.1001011 has four 1s, already even, so the parity bit is 0: 01001011.
• b.11001001 has four 1s: even, so the check passes, and the receiver accepts it. But compare it with what was sent: the first bit (the parity bit) and the seventh bit both flipped. Its data, 1001001, is the letter I, not K. Two flips cancel out in the count, so the damage isn’t noticed.
• c.Any even number of flipped bits, as in b. A parity bit catches only an odd number of flips, and only says that a byte is damaged, not which bit. TCP’s checksum, a 16-bit sum of the whole segment, catches every single flipped bit and most pairs; the CRC at the end of every frame is stronger still. Each layer’s check catches damage the others might miss, and a segment that fails is sent again.

• a.member (student_id PK, name, class); book (book_id PK, title, author); loan (loan_id PK, book_id FK, student_id FK, date_out, date_back).
• b.Member to book is many-to-many: a member borrows many books, and a book is borrowed by many members. It is resolved into the link entity loan, one row for each time one member borrows one book, with its own attributes, the dates. (Its key can’t be just (book_id, student_id), because the same member may borrow the same book twice; so loan gets its own key, loan_id, or the key (book_id, student_id, date_out).)
• c.Three boxes, each with its attributes, PK and FK marked. A line from member to loan: two bars next to member (each loan is for exactly one member), a ring and a fork next to loan (a member has zero or many loans). A line from book to loan, marked the same way: two bars next to book, a ring and a fork next to loan.

• a.Update: a driver’s phone number is written in every ticket for that bus; change it in some rows and not others, and the table gives two numbers. Insertion: a new bus, with its route and driver, can’t be recorded until someone buys a ticket for it. Deletion: deleting the only ticket ever sold for a bus loses which route it runs and who drives it.
• b.The table is in 1NF (one value per field, key ticket_no) and, with a single-column key, in 2NF. It isn’t in 3NF: route, driver and driver_phone depend on bus_no, and driver_phone on driver, none of which is the key (transitive dependencies). Each group of facts goes to the table of the thing it is about:

• drivers (driver_id PK, name, phone)
• buses (bus_no PK, route, driver_id FK → drivers)
• passengers (passenger_id PK, name, phone)
• tickets (ticket_no PK, bus_no FK → buses, travel_date, seat, passenger_id FK → passengers)

Each non-key field now gives a fact about its table’s key, the whole key and nothing but the key: 3NF. (The passenger needs some thought: the old table has no passenger ID and names aren’t unique, so its passenger_name and passenger_phone could be taken as facts about the ticket. Giving passengers a table of their own, with an ID, writes a regular passenger’s phone once. Drivers get an ID for the same reason.)
c. Every foreign key must point to a real row: the database refuses a ticket for a bus_no that isn’t in buses, and refuses to delete a bus, a driver or a passenger that tickets still point to. So the data can never contain a ticket on a bus that doesn’t exist.

a. Each phone listens before sending and waits while anyone else is sending. When the air is quiet, it waits a further random number of time slots, so phones waiting together rarely start together. It sends, and the access point answers each frame with an ACK. If no ACK comes, the frame was probably lost in a collision: the phone waits again, choosing from a range twice as long each time, and resends. RTS/CTS can book the air for a long frame, against hidden stations that can’t hear each other.
In the evening, many phones share one channel and, for the most part, only one can send at a time. More phones mean more waiting, more collisions (two choosing the same wait), longer waits after each one, and more frames sent twice. Phones with a weak signal send slowly and hold the air longer, and neighboring networks on the same channel share the same air. The bottleneck is the air around the access point, not the connection behind it.
b. A static route is typed into a router by hand and stays until someone changes it: enough for a home router with one way out. In dynamic routing, routers tell their neighbors which addresses they can reach, using a routing protocol (OSPF inside a network, BGP between networks), and build their tables from what they hear. The internet’s core has many thousands of routers and links that break and change every day; no one could update every table by hand, and only dynamic routing finds a way round a break within seconds or minutes.