Socket Programming

Computer Network & Network Security System — Application Layer, NEC licence examination syllabus (Nepal Engineering Council).

Socket Programming: where "networking theory" becomes actual code

Every network app you've ever used was built by a programmer calling functions with names like "bind" and "listen."

A socket is the programming interface (an API) that lets an application actually send/receive data over a network — it's the code-level handle you hold onto, which sits on top of everything covered in this whole networking subject.

💻 Client-Server Socket Model

Server sidecreate socket → bind to a port → listen for connections → accept a connection → send/receive data.

Client sidecreate socket → connect to server's address+port → send/receive data.

TCP sockets (SOCK_STREAM) give you a reliable, connection-oriented byte stream. UDP sockets (SOCK_DGRAM) give you fast, connectionless datagrams — you choose based on the same TCP-vs-UDP tradeoffs covered in the transport layer chapter.

💡 One-liner: "What's the difference between bind() and connect() in socket programming?" → bind() reserves a local port to listen ON (server-side); connect() reaches OUT to a remote address (client-side).

Why the server needs both listen and accept

The sequence looks like it has one call too many. It does not, and the reason is the most useful thing in this topic.

socket() create an endpoint — not yet attached to anything bind() attach it to a specific port, so the OS knows which incoming segments belong to this program listen() mark it PASSIVE: this socket will never send data, it only waits for connection requests and queues them accept() take one queued request and return a BRAND NEW socket dedicated to that one client

The listening socket and the connected socket are different sockets. The listening one keeps waiting for the next client; the new one carries the conversation with this client. That separation is what lets a server hold thousands of simultaneous connections on a single port — each accept() produces another socket, distinguished by the 4-tuple covered in the transport-layer chapter.

💡 Exam question: "a web server has one process on port 80 — how does it serve many clients?" The full answer is accept() returning a new socket per connection, each identified by the source IP and source port that make its 4-tuple unique. One listening socket, many connected ones.

Why the client is shorter

A client calls socket() then connect(), and skips bind(), listen() and accept() entirely.

🔌 What the client does not need

No bindThe OS assigns an ephemeral port automatically. A client does not care which port it uses — only that it is unique — whereas a server must be found at a known one.

No listen or acceptThe client initiates rather than waits, so there is nothing to queue.

That asymmetry is the client-server distinction, expressed in code: the server must be reachable at a predictable address and waits; the client knows where it is going and initiates. Nothing else separates the two roles.

TCP and UDP sockets differ in shape

📞 Connection or not

TCPsocket → bind → listen → accept, then send/recv on the accepted socket. A connection exists, so neither side repeats the address.

UDPsocket → bind, then sendto/recvfrom. No connection, no listen or accept — every datagram carries its own destination, and recvfrom reports who sent it.

💡 This mirrors the demultiplexing rule exactly: TCP sorts on four values because a connection exists to identify, while UDP sorts on two because a datagram is standalone. The API shape follows from the transport semantics rather than being an arbitrary interface choice.

The blocking behaviour that surprises people

accept() and recv() block by default — the program stops there until something arrives. A single-threaded server that calls recv() on one client cannot accept anyone else meanwhile.

That is why real servers use threads, processes, or an event loop with select/poll. The naive sequence in a textbook handles exactly one client at a time, which is worth stating plainly since the code looks complete and is not.

Syllabus points

Socket concept; client-server model
TCP vs UDP sockets

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.