Serial and parallel transmission — Serial transmission sends a sequence of bits over a communication channel; parallel transmission sends several bits simultaneously on separate lines. Parallel is not automatically faster in a real installation: line count, distance, clocking and signalling rate matter. Modern serial links can carry data at high rates without needing many perfectly aligned data lines.
Skew and interference — In a parallel link, different propagation delays can make bits of one group arrive at different times, called skew. Nearby lines can also interfere through crosstalk, where a signal on one line causes an unwanted signal on another. Serial transmission reduces the number of data lines and the alignment problem between multiple parallel bits; it does not abolish noise, propagation delay or every possible timing problem.
Synchronous transmission — Synchronous communication maintains a timing relationship so the receiver can identify symbol boundaries, using a shared or recovered clock as appropriate to the link. Data can be sent in blocks without a separate start and stop bit for every character. Synchronisation and framing still have costs; synchronous does not mean the sender and receiver perform every application operation simultaneously.
Asynchronous character framing — In a simple asynchronous serial link, each character is framed by a start bit and one or more stop bits, allowing the receiver to resynchronise timing for each character. The endpoints still agree a nominal signalling rate and format. A conventional idle-high example starts with a low start bit and finishes high; the agreed format, not the everyday meaning of asynchronous, determines the details.
Framing overhead example — For a declared 8-data-bit, no-parity, one-start/one-stop format, one character needs 10 transmitted bits. At 9600 bits per second the theoretical sustained maximum is 960 characters per second, ignoring additional gaps and other protocol costs. The payload is the useful data carried, excluding framing and other control information. The payload fraction is 8/10 = 80 percent; do not count the framing bits as useful character data.Declared eight-data-bit, no-parity, one-start/one-stop format. Ten transmitted bits carry eight payload bits, giving a theoretical 960 characters per second at 9600 bits per second with no gaps and 80% payload fraction. This is a logical field sequence, not a voltage waveform or a universal asynchronous format.
Symbols and bits — Baud rate measures transmitted symbols per second; bit rate measures bits per second. If a coding scheme represents exactly 4 distinct symbols, each carries 2 bits and 2400 baud corresponds to 4800 bits per second before other overhead. A symbol need not cause a literal voltage transition on every interval, so symbol rate is the more precise interpretation than counting every edge.
Bandwidth and achievable rate — Physical channel bandwidth is a frequency range measured in hertz; networking also uses bandwidth informally for data-carrying capacity in bits per second. With comparable signalling and noise conditions a wider channel can support a higher data rate, but exact rate also depends on modulation, coding and noise. Do not equate one hertz with one bit per second for every possible link.
Latency and transfer time — Latency is delay before or during communication, influenced by propagation, processing and queuing. High throughput does not guarantee low latency. An ideal 8 megabit payload at 2 megabits per second needs 4 seconds of transmission time before additional delays and overhead; a short interactive exchange may be dominated by latency rather than payload size.
Protocols and interoperability — A protocol specifies agreed communication rules such as message format, sequence, addressing and responses to errors. Agreement is needed at the relevant layer; merely connecting two cables does not ensure the applications understand each other. Distinguish a protocol specification from a particular program implementing it.
Local networks, topology and wireless access
Physical and logical topology — Physical topology describes connections between devices; logical topology describes how communication flows or access to a medium is organised. A central hub with separate cables forms a physical star while repeating traffic as a shared logical bus. A switched Ethernet star normally provides separate links, so not every star behaves as a bus.Four separate peripheral cables connect to a hub in a physical star. Repetition shares traffic as a logical-medium arrangement. A switched star is a different forwarding arrangement and should not automatically be described as a logical bus. This schematic represents topology rather than actual cable lengths or collision timing.
Star operation and failures — A star's central device connects each peripheral through its own link. One peripheral cable failure usually isolates that connection, while failure of the relevant central device can affect many attached hosts. Redundancy and device type alter the actual risk; topology alone does not prove a network has no single point of failure.
Peer-to-peer organisation — Peers can request and provide resources without a dedicated hierarchy of client machines and central service machines. This can suit a small sharing arrangement, but distributed permissions, availability and backups can become harder to manage consistently. Equal role status does not guarantee equal hardware capacity, trust or workload.
Client-server organisation — A client requests a service and a server provides it, such as file storage, authentication or email handling. Centralised management and backups can help administration but need capacity and continuity planning. A server is a role, not necessarily a particular size of computer; one host can run several server processes and can itself act as a client elsewhere.
Wireless components and SSID — A wireless adapter communicates by radio with a wireless access point in a typical infrastructure WLAN. The service set identifier, SSID, identifies the wireless network name; it is not the encryption key. An access point connects wireless stations to the relevant network and need not itself perform routing, DHCP or internet access, though a domestic box can combine these roles.
Wireless protection and its limits — Use appropriate current wireless authentication/encryption and strong credentials. The specification names WPA/WPA2; original WPA and obsolete modes should not be presented as the strongest current choice, and WPA3 is a later development. Hiding an SSID does not make traffic invisible, and MAC allow lists can be bypassed by copying an allowed address; neither replaces effective encryption/authentication.
Carrier sensing and avoidance — Carrier sense multiple access with collision avoidance (CSMA/CA) allows several stations to share a medium. In CSMA/CA a station listens before attempting transmission, waits while the medium is busy and uses the relevant backoff procedure to reduce simultaneous attempts. An acknowledgement can indicate successful receipt; missing acknowledgement can lead to retry. Avoidance reduces collision risk rather than guaranteeing collisions never occur, and wireless stations cannot generally rely on detecting collisions while transmitting as a shared wired model might.
RTS, CTS and hidden stations — Optional request-to-send and clear-to-send exchanges reserve an intended transmission period so stations hearing the relevant frames defer. This helps with hidden stations that cannot hear each other but can interfere at an access point. RTS/CTS adds overhead and does not eliminate interference or every collision, especially where the reservation exchange itself competes.
Internet structure, packets and naming
Networks of networks — The Internet interconnects independently managed networks using agreed protocols and routing. The World Wide Web is one application using that infrastructure, not a synonym for the whole Internet. A local network can use IP without being publicly connected to the Internet.
Packet switching — A message can be divided into packets that share links with other traffic. Routers forward individual packets according to relevant destination information and routing tables; routes can differ and packets can be delayed, lost, duplicated or reordered. Reliable ordered delivery, when required, needs an appropriate end-to-end transport such as TCP rather than an assumption that IP guarantees it.
Packet contents and layers — A typical IP packet includes addressing and control information in its header plus a payload. A transport segment inside the payload can carry source/destination ports and sequence information where that transport defines them. Link frames add their own local-link headers/trailers; do not assume every protocol places all possible fields in one identical packet layout.
Routing decisions — A router examines destination IP information and chooses a suitable next hop from its routing information. It need not know a complete fixed route for every packet in advance. Routing policy, available routes and changing network conditions matter; the fewest routers is not necessarily the selected or best route under every policy.
Router and gateway roles — A router forwards packets between IP networks. Gateway is a broader role at a boundary, sometimes translating protocols or providing access to another system; a host's default gateway is commonly its local router. Describe the actual role rather than assuming router and every use of gateway mean exactly the same device function.
URL structure — In the invented example https://revision.example.org:443/topics?id=7#notes, the scheme is https, host is revision.example.org, explicit port is 443, path is /topics, query is id=7 and fragment is notes. The fragment normally guides the client within a resource and is not sent as part of the HTTP request target. A URL identifies a resource/location and access scheme, not merely an IP address.
Names, addresses and hierarchy — A domain name is organised hierarchically in labels, such as org, example and revision in revision.example.org. A fully qualified domain name specifies the complete name to the root, conventionally shown with a final dot in explicit DNS notation. An IP address identifies an interface/addressed endpoint, a device's relevant network connection in this context; one host name can resolve to several addresses and one server address can serve many names.
DNS resolution — A client normally asks a recursive resolver, which may answer from a valid cache or query relevant Domain Name System (DNS) servers, following referrals through the hierarchy as needed. Authoritative servers supply relevant records for their zones. DNS does not search every server on the Internet, and not every name lookup returns exactly one IPv4 address; different record types support different purposes.
Registries and coordinated allocation — Coordinated registries and allocation organisations help keep names, number resources and delegations appropriately managed. IANA coordinates global IP/AS number resources with regional Internet registries, while domain registries manage relevant domain registration data through their arrangements and registrars. Do not claim every IP address is manually issued directly to a person by a single DNS server.
Internet security, trust and malicious software
Packet-filtering firewall — A packet filter allows or blocks traffic using rules about relevant header fields such as source/destination addresses, protocol and ports. It can reduce unwanted exposure but cannot prove all allowed content safe. Rules, direction and the device's position matter; a permitted port is not an automatic guarantee of a trustworthy application.
Stateful inspection and proxies — A stateful firewall tracks connection state to distinguish expected traffic in established exchanges from unsolicited traffic under its rules. A proxy intermediates application requests and can apply policy at that level. A proxy does not inherently decrypt every encrypted conversation; inspection depends on its role and the actual trust/encryption arrangement.
Symmetric encryption — The parties use the same secret key, or closely related secret key material under the scheme, for encryption and decryption. It can efficiently protect bulk data but the secret must be established and protected. A shared secret cannot simply be sent openly alongside the ciphertext without undermining its confidentiality.
Asymmetric encryption and key establishment — Public/private key cryptography uses mathematically related keys with different roles. A public key can support encryption to its private-key holder under a suitable encryption scheme, while other schemes establish shared key material or verify signatures. Modern secure connections commonly authenticate and establish secrets using asymmetric methods, then protect application traffic with efficient symmetric cryptography; not all use a literal transmission of a pre-existing secret key.
Digital signature purpose — A signer uses a private signing key with an appropriate signature scheme over relevant message data, commonly through a cryptographic digest, a fixed-length value calculated from message data by a cryptographic hash function. Verification uses the corresponding public key to check integrity and origin relative to that key. A signature does not hide the message, prove the content morally correct or by itself establish the real-world identity of an unknown key holder.
Certificates and trust — A digital certificate binds a public key to an identified subject under stated information and is signed by an issuing authority. A client validates the relevant trust chain, names, validity and other applicable checks before relying on the binding. An attacker can create a key pair or self-signed certificate, so possession of a certificate alone is not universal proof of trusted identity.
Obtaining and using certificates — A subject normally generates or controls a key pair and requests certification with evidence required by the issuer's policy. The issuer signs a certificate containing the public key and relevant identity information; the private key must remain protected. In a web connection the server presents its certificate chain and proves relevant private-key control through the protocol, rather than publishing the private key to visitors.
Viruses, worms and trojans — A virus attaches to or depends on a host file/program and propagates when the relevant infected code runs. A worm can propagate across systems without attaching itself to such a host program, often exploiting exposed weaknesses. A trojan presents itself as useful or legitimate while carrying unwanted malicious behaviour; the categories describe mechanisms and can overlap in one attack.
Reducing malware risk — Defensive coding, validation, memory-safety measures where applicable, updates, least privilege, giving each account or program only the permissions it needs, and limiting exposed services reduce exploitable opportunities. Monitoring, protection tools and appropriate response can detect or contain some attacks but are not perfect. Backups and tested recovery reduce consequences; a backup is not the same as preventing initial infection, and a trusted-looking attachment is not automatically safe.
TCP/IP layers, endpoints and applications
Four-layer model — The application layer defines services and message meaning; transport supports communication between application endpoints; the network layer addresses and routes packets across networks; the link layer transfers frames on a local link. This is the four-layer TCP/IP model used here, not a claim that the seven-layer OSI model has only four layers.
Encapsulation and delivery — Application data becomes the payload of a transport unit, which is carried inside an IP packet, which is carried inside a link frame. The receiver interprets the relevant headers as the data moves up its stack. Routers normally replace local-link framing for the next link while forwarding the IP packet with relevant network-header changes; an end-to-end destination IP is not generally replaced with each router's address.A four-layer teaching model carries application data inside a transport unit, inside an IP packet, inside local-link framing. The receiver interprets the layers in reverse. Header sizes and payload lengths are not drawn to scale; routing changes local-link framing rather than replacing the final application destination with each router.
TCP and UDP roles — TCP provides an ordered reliable byte stream using sequencing, acknowledgements and retransmission as appropriate, without preserving application message boundaries for the programmer. UDP sends datagrams, separately addressed message units, without TCP's built-in reliability/order guarantees and can suit latency-sensitive or independently managed exchanges. Lower overhead alone does not make one universally better; applications choose or add the properties they need.
Sockets and ports — A socket is an operating-system communication endpoint used by an application; an Internet socket is associated with protocol and address/port information as appropriate. A TCP connection is distinguished by its endpoint address/port pair at each end. Ports select relevant application services/endpoints on a host; they are not physical cable sockets and not a replacement for IP addressing.
Server and client ports — A server commonly listens on an agreed service port, while an initiating client commonly uses a temporary local port so replies reach the right connection. Different concurrent clients or connections can contact the same listening service. Default port assignments are conventions and services can be configured elsewhere; choosing port 443 does not itself add encryption.
Web requests and rendering — A browser resolves the host as needed, establishes the appropriate connection, sends HTTP requests and receives responses. A web server returns resources such as HTML, and the browser parses content, retrieves referenced resources and renders the page, running permitted client scripts. The server's application/database code does not automatically execute inside the browser merely because its result appears there.
HTTP and HTTPS — HTTP defines request/response methods, status and headers for transferring representations. HTTPS protects HTTP using TLS, providing confidentiality/integrity in transit and authentication under the validated certificate/trust arrangement. It does not guarantee an honest business, harmless downloaded content or correct application logic after decryption.
FTP use — An FTP client communicates with an FTP server to list and transfer files under the protocol. Access may be anonymous with restricted public permissions or authenticated with account credentials. Ordinary FTP does not itself encrypt credentials or transferred data; secure alternatives have distinct protocols or protection arrangements, and SFTP is an SSH-based protocol rather than simply another name for plain FTP.
Email roles and protocols — SMTP handles submission/transfer of outgoing messages to the relevant mail infrastructure and between servers. POP3 retrieves messages from a mailbox server, with deletion/retention behaviour depending on commands and client settings rather than a universal rule that reading always deletes every copy. A provider can combine sending and mailbox roles; POP3 is not the protocol used to send an outgoing message to another mail server.
SSH and remote management — SSH establishes an authenticated encrypted channel used for remote login, command execution and other supported functions. Verify the server host key through an appropriate trust process rather than accepting any unfamiliar identity as proof. A client such as an OpenSSH command-line client or an appropriate terminal application can be used to administer a host where access is authorised.
Tunnels and textual protocols — An SSH tunnel can forward a local port through an encrypted connection to a specified destination, allowing an appropriate client to communicate with a service. For a permitted plain HTTP/1.1 teaching service, a request includes GET / HTTP/1.1 and a Host header followed by a blank line; mail protocols have their own command sequences and response states. Do not send live mail, probe third-party systems or assume modern public services permit unencrypted manual sessions; practise on authorised local or supplied examples.
Addresses, subnets and connection configuration
IPv4 and IPv6 — IPv4 addresses are 32 bits, commonly displayed as four decimal octets, groups of eight bits written here as numbers from 0 to 255. IPv6 addresses are 128 bits, commonly displayed as hexadecimal groups with defined abbreviation rules; the much larger address space addresses IPv4 allocation pressure and supports other design developments. IPv6 is not simply four times as many possible addresses: the number of bit patterns grows exponentially with bit length.
Prefix and host portions — An address prefix identifies the relevant network/subnet and the remaining bits distinguish addresses within that prefix. The split is given by a prefix length or mask rather than necessarily by the first one, two or three decimal octets. The same textual address alone does not specify every routing or subnetting decision without the applicable configuration.
Masking a subnet — For 192.0.2.130/26 the mask is 255.255.255.192. Bitwise AND of address and mask gives 192.0.2.128; the last-octet range is 128 through 191. In an ordinary IPv4 /26 subnet, 128 is its network identifier and 191 its broadcast address, leaving 129 through 190 as 62 conventional host addresses; special /31 and /32 contexts do not follow that ordinary subtraction rule.
Binary mask method — The last octet 130 is 10000010 and mask octet 192 is 11000000, so AND gives 10000000 = 128. For /26, 6 bits remain after the prefix and 2^6 = 64 address patterns exist in the block. Compare masked prefixes to test same-subnet membership under the declared mask, rather than comparing only the first three decimal numbers for every network.Documentation address 192.0.2.130/26 uses mask 255.255.255.192. Last-octet AND yields 128, so the ordinary IPv4 block runs 128 through 191, with network 128, broadcast 191 and conventional hosts 129 through 190. There are 64 patterns and 62 conventional host addresses; special prefix contexts need their own rules.
Public and private scope — Publicly routable addresses can participate in global Internet routing under the relevant allocation/policy. RFC1918 private IPv4 ranges 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are intended for private use and are not globally routed as those private addresses. Not every nonpublic address is RFC1918 private: loopback, link-local, documentation and other special-purpose ranges have distinct roles.
DHCP configuration — A Dynamic Host Configuration Protocol (DHCP) client can obtain a time-limited lease and relevant configuration such as an address, subnet mask/prefix, default gateway and DNS resolver information from the configured service. A simplified IPv4 acquisition exchange is discover, offer, request, acknowledge. DHCP can reserve a stable assignment as well as allocate from a pool; it does not guarantee every connection receives a permanently new address.
NAT and port translation — Network address translation rewrites relevant address information across a boundary; common home sharing uses address-and-port translation to map several internal connections onto one public address. For example, private source 192.168.1.10:51000 can map to public 203.0.113.5:62001 for a particular connection, with state translating replies back. The public address here is a documentation example, not a real service; NAT is not encryption or a complete security policy.
Port forwarding — A configured inbound mapping can send traffic arriving at a public address/port to an internal service, such as documentation address 203.0.113.5:8443 to private 192.168.1.20:443. The service and firewall still need correct security and authorisation. It differs from an SSH tunnel: an ordinary NAT forwarding rule does not by itself create an encrypted channel or change HTTP into HTTPS.
Interactive web systems and client processing
Client-server exchanges — In a request/response interaction the client initiates a message and the server replies with an appropriate result or error. A browser can request a page and later send further API requests without reloading all its content. A server must validate inputs and enforce relevant permissions; a disabled browser button is not a trustworthy security boundary.
Persistent WebSocket communication — A WebSocket connection supports bidirectional messages between client and server over a persistent connection, allowing server-initiated updates after establishment. It suits features such as live collaboration or status feeds where appropriate. A usual HTTP/1.1 establishment begins with an upgrade handshake; do not describe WebSocket as ordinary repeated GET polling or claim application authentication and validation become unnecessary.
CRUD and REST principles — CRUD means create, retrieve/read, update and delete. A web API can expose resources through HTTP methods while server code validates requests and performs relevant database operations. REST concerns an architectural style and resource interaction, not a requirement that every URL be a database table or every method always execute exactly one SQL statement.
Method semantics and the teaching mapping — GET conventionally retrieves a representation, POST commonly submits for creation or processing, PUT replaces the target representation and DELETE requests removal. The specification's simple mapping GET to SELECT, POST to INSERT, PUT to UPDATE and DELETE to DELETE is useful for an illustrative data application, but actual server behaviour must implement the intended semantics. GET should not be used to perform a state-changing deletion; a method name alone does not enforce permissions.
JSON and XML representations — JavaScript Object Notation (JSON) represents values such as objects, arrays, strings, numbers, booleans and null; Extensible Markup Language (XML) structures information using elements, attributes and text. In an invented JSON example {"id":7,"name":"Ada"}, the equivalent simple XML could be <learner id="7"><name>Ada</name></learner>. JSON is often more compact for such data, while XML supports its own document and schema conventions; human readability and parsing speed depend on the data, tools and workload rather than a universal guarantee.
API and database boundary — Browser JavaScript can send a JSON request to a server API, which authenticates/authorises, validates and executes a parameterised database operation before returning a permitted response. The browser should not receive a privileged database password to bypass that boundary. An application can use XML or other suitable representations as well as JSON; a file extension alone does not establish trust.Conceptual request-processing sequence for a data application: browser request, server authentication/authorisation and validation, appropriate parameterised database operation, permitted response. The response eventually returns to the browser. It is not a complete security design or a claim that each request always executes one SQL statement.
Thin and thick clients — A thin client relies more on remote processing/storage; a thick client performs more work locally. Compare deployment, connectivity, local resources, offline operation, administration and data exposure for the actual design. The distinction is relative: a browser application can perform substantial local processing and a desktop application can still rely on a remote service.
Test yourself
50 questions · Random sets of 10. These quick checks support revision; practise longer explanations and justified judgements too.
Mr Kidman's Classroom
