Sockets & Network Programming in C

This is the single highest-signal topic for a networking-appliance embedded interview, and for good reason: the entire product is software that sits in the path of network traffic, so understanding what a connection actually is at the C/socket level is closer to the job than almost anything else in this track.

A socket is an endpoint for communication, represented in C as a file descriptor -- once you have one, read/write/close work on it much like a file, because the kernel deliberately unified that interface. Creating one is socket(domain, type, protocol) -- domain picks the address family (IPv4 vs. IPv6), type picks the transport (stream vs. datagram), protocol is almost always left to the kernel to infer from type.

TCP is connection-oriented and reliable; UDP is connectionless and makes no promises. TCP establishes a connection first (the three-way handshake: SYN, SYN-ACK, ACK), guarantees delivery and ordering by retransmitting lost segments and buffering out-of-order ones, and tears the connection down explicitly when done. That reliability costs latency and per-connection state. UDP just sends a packet -- no handshake, no guarantee it arrives, no guarantee of order if more than one is sent -- which is exactly why it's the right choice for things where a late or lost packet is worse than a dropped one: DNS lookups, video/voice streams, and a lot of the low-level protocols this kind of appliance inspects.

The socket API's server side has a specific, memorisable sequence: socket() creates the endpoint, bind() attaches it to a local address and port, listen() marks it ready to accept incoming TCP connections and sets a backlog queue size, accept() blocks until a client connects and returns a new socket specifically for that connection (the original listening socket keeps listening for the next one). The client side is simpler: socket() then connect() to the server's address. UDP skips listen/accept/connect entirely and just uses sendto/recvfrom, since there's no connection to establish.

DNS turns a hostname into an IP address, over UDP by default (falling back to TCP for responses too large for a single UDP packet) -- a client asks a resolver, the resolver may ask further up a hierarchy of authoritative servers, and the answer gets cached for the response's TTL. ARP does a related but different job at a lower layer: given an IP address already known to be on the local network segment, ARP finds the corresponding MAC (hardware) address, because Ethernet frames are addressed by MAC, not IP -- DNS resolves names to IPs across the internet, ARP resolves IPs to hardware addresses on the wire you're actually sitting on.

HTTPS is HTTP carried inside a TLS-encrypted connection, not a separate protocol on the wire -- the TLS handshake (negotiating an encryption method and exchanging keys) happens first, then ordinary HTTP request/response traffic flows encrypted inside it. That a firewall or security appliance can't read HTTPS payloads without terminating and re-establishing the TLS session itself (a deliberate, visible act, not a side effect) is a real, current tension in exactly the kind of product this interview is for.