C++ Networking

By the end of this lesson you'll understand how programs talk over a network in C++: when to choose TCP or UDP, the exact order of the BSD socket calls, how a TCP echo client and server exchange bytes, the difference between blocking and non-blocking I/O, and which higher-level libraries (Boost.Asio, POCO) save you from writing it all by hand.

1. TCP vs UDP — picking the right pipe

Every networked program starts with one choice: do you need reliability or raw speed? TCP (Transmission Control Protocol) gives you a reliable, ordered byte stream — the OS resends lost packets and reassembles them in order, so what you send is exactly what arrives. UDP (User Datagram Protocol) skips all that bookkeeping: each datagram is fired off independently, may be lost, and may arrive out of order — but with almost no overhead. You pick the protocol when you create the socket: SOCK_STREAM for TCP, SOCK_DGRAM for UDP.

// ⚠️ This is a WORKED EXAMPLE to read — the live editor has no network,
//    so socket calls are shown commented. Run it to see the explanation print.
#include <iostream>
using namespace std;

int main() {
    // TCP = a phone call. You dial, a connection is established, then
    // every word arrives in order, with nothing lost. The OS resends
    // anything that goes missing. Reliable but slightly slower to set up.
    //
    // UDP = posting letters. You just drop a datagram in the box. No
...

2. The BSD Sockets API — call order matters

Nearly every language's networking sits on top of the BSD sockets API — a small set of C functions that originated in Berkeley Unix and now run everywhere (Windows calls its near-identical version Winsock). The functions must be called in a specific order. A server goes socket → bind → listen → accept, then exchanges data and closes. A client is shorter: socket → connect, then exchange and close. The key surprise: accept() returns a brand-new socket dedicated to that one client, leaving the original socket free to accept the next.

// ⚠️ WORKED EXAMPLE — real socket calls are commented (no network in the
//    editor). The point is the ORDER of calls. Run it to print the recap.
#include <iostream>
using namespace std;

// Real headers you would include on Linux/macOS:
//   #include <sys/socket.h>   // socket(), bind(), listen(), accept()...
//   #include <netinet/in.h>   // sockaddr_in, htons()
//   #include <arpa/inet.h>    // inet_pton()
//   #include <unistd.h>       // close()

int main() {
    cout << "SERVER call ord
...

3. A TCP Echo Server & Client

The "hello world" of sockets is an echo service: the server sends back whatever the client sends it. Read the server first — note how it checks every return code, sets SO_REUSEADDR, converts the port with htons(), and loops on recv() until the client closes. Then read the matching client. These can't run in the editor (no live network), so the expected exchange is written at the bottom of each example.

// ⚠️ WORKED EXAMPLE: a TCP ECHO server (sends back whatever it receives).
//    Real socket code is shown but cannot run in the editor's sandbox —
//    study the flow and the comments. The expected EXCHANGE is at the bottom.
#include <iostream>
#include <cstring>
using namespace std;
// On Linux/macOS also: <sys/socket.h> <netinet/in.h> <arpa/inet.h> <unistd.h>

int main() {
    // 1) Create a TCP socket. Returns -1 on failure — ALWAYS check it.
    // int srv = socket(AF_INET, SOCK_STREAM, 0)
...

Here's the other half. The client creates a socket, connect()s to the server's IP and port, sends a message, and reads the echoed reply. Notice that send() and recv() are not guaranteed to move all the bytes in one call — robust code loops, which we'll lean on in the exercises.

// ⚠️ WORKED EXAMPLE: the matching TCP ECHO client. Commented socket calls,
//    runnable summary at the end. Pair it with the echo server above.
#include <iostream>
#include <cstring>
using namespace std;

int main() {
    // 1) Create the socket and check the result.
    // int s = socket(AF_INET, SOCK_STREAM, 0);
    // if (s < 0) { perror("socket"); return 1; }

    // 2) Point at the server. inet_pton converts "127.0.0.1" text -> bytes.
    // sockaddr_in addr{};
    // addr.sin_family = A
...

Your turn — and this one runs. After recv() hands you raw bytes, the very first thing real servers do is parse them. Below is the first line of an HTTP request; split it into its three fields with an istringstream. Fill in the blank, then run it.

#include <iostream>
#include <sstream>
#include <string>
using namespace std;

int main() {
    // 🎯 YOUR TURN — runnable plain logic: parse one HTTP request line.
    // A request line looks like:  "GET /index.html HTTP/1.1"
    // Network code does exactly this after recv() hands you raw text.

    string requestLine = "GET /index.html HTTP/1.1";

    // istringstream lets you pull words out with >> , splitting on spaces.
    istringstream iss(requestLine);
    string method, path, version;


...

4. Blocking vs Non-Blocking I/O

By default, socket calls are blocking: recv() pauses your thread until data shows up. That's easy to reason about, but a single slow client stalls the whole thread — so blocking servers typically spawn one thread per connection. Non-blocking sockets return immediately; if nothing is ready, recv() hands back -1 with errno == EWOULDBLOCK instead of waiting. That lets a single thread watch thousands of sockets using an OS "readiness" mechanism — epoll on Linux, kqueue on BSD/macOS, IOCP on Windows. More scalable, but more complex to write correctly.

// ⚠️ WORKED EXAMPLE — fcntl()/select() are commented (no live sockets).
//    Run it to print the trade-off recap.
#include <iostream>
using namespace std;
// Real: #include <fcntl.h>  #include <sys/select.h>

int main() {
    // BLOCKING (the default): a call like recv() PAUSES your whole thread
    // until data arrives. Simple to read, but one slow client stalls you,
    // so a blocking server usually needs one thread per connection.
    //   recv(s, buf, len, 0);   // sleeps here until byt
...

Another runnable exercise. Because TCP can split or merge your messages, real protocols frame each message with its length, like 5|hello. Build that frame from a payload — fill in the blank to write the length prefix, then run it to watch it decode again.

#include <iostream>
#include <sstream>
#include <string>
using namespace std;

int main() {
    // 🎯 YOUR TURN — runnable plain logic: build a length-prefixed "frame".
    // Because recv() can split or merge messages, real protocols prefix the
    // payload with its length, like:  "5|hello"  (5 bytes, then the text).

    string payload = "hello";

    // 1) Build the frame: the payload's size, then '|', then the payload.
    ostringstream oss;
    oss << ___ << "|" << payload;   // 👉 payloa
...

5. Higher-Level Libraries: Boost.Asio & POCO

Writing raw sockets teaches you what's happening, but in real projects you'll usually reach for a library that smooths over the sharp edges — non-blocking I/O, timeouts, SSL/TLS, and the differences between POSIX and Windows. The two most common in C++ are below.

// Boost.Asio sketch (conceptual):
// boost::asio::io_context io;
// tcp::acceptor acceptor(io, tcp::endpoint(tcp::v4(), 8080));
// acceptor.async_accept([](error_code ec, tcp::socket sock){ /* handle */ });
// io.run();   // the event loop drives all callbacks

// POCO sketch (conceptual):
// Poco::Net::ServerSocket srv(8080);
// Poco::Net::StreamSocket conn = srv.acceptConnection();
// conn.sendBytes(data, len);   // friendlier, blocking by default

#include <iostream>
#include <sstream>
#include <string>
using namespace std;

int main() {
    // 🎯 MINI-CHALLENGE: parse a "KEY VALUE" config/command line
    // Servers often read simple text commands. Parse:  "SET name Alice"
    //
    // 1. Put the line "SET name Alice" in a string.
    // 2. Use an istringstream and >> to pull out three words:
    //    command (SET), key (name), value (Alice).
    // 3. Print:  command=SET key=name value=Alice
    // 4. BONUS: if command == "SET", also 
...