Exercises — Socket programming — TCP server - client, UDP server - client in Python

• (a) TCP. SOCK_STREAM = ek reliable, ordered byte stream. Socho bytes ka ek continuous pipe.
• (b) UDP. SOCK_DGRAM = independent datagrams (postcards). Har sendto ek self-contained packet hota hai.
• (c) UDP. recvfrom (data, addr) return karta hai — tum jaante ho kisne bheja kyunki koi fixed connection nahi hai. TCP plain recv use karta hai (peer already known hota hai).
• (d) TCP. listen ek socket ko passive banata hai (incoming calls queue karne ke liye willing). UDP ke paas queue karne ke liye koi calls nahi hoti, isliye yeh kabhi listen use nahi karta.

• '127.0.0.1' = IP address (yahan loopback address = "yahi machine").
• 9000 = port = us machine par kaun sa darwaza is program ko answer karta hai. Dono milke us socket ka local address banate hain jo woh claim karta hai. Dekho Ports and IP addressing. Client ko exactly is (IP, port) ko target karna hoga server tak pahunchne ke liye.

• conn = ek brand-new socket sirf is ek client ke liye dedicated.
• addr = client ka (IP, port). Original listening socket s ko doosre clients accept karte rehne ke liye free rehna chahiye. Isliye OS tumhe actual conversation ke liye ek alag socket deta hai. Yahi split reason hai ek server bahut saare clients serve kar sakta hai: ek listener, bahut saare conns.

• A = socket.SOCK_STREAM (TCP).
• B = listen — passive ho jao. 1 backlog hai (waiting-bench size jo page ke upar define ki gayi hai): yahan zyada se zyada 1 completed-but-unaccepted connection wait kar sakti hai.
• C = accept — block karta hai jab tak client connect nahi karta, per-client socket return karta hai.
• D = recv — stream se 512 bytes tak padho. Order matter karta hai: listen se pehle accept nahi kar sakte, aur bind se pehle listen/accept nahi kar sakte (pehle address chahiye).

Sockets bytes carry karte hain, str nahi. Client fix karo:

c.send("hello".encode())   # or  c.send(b"hello")

Server par, text mein decode karo:

text = conn.recv(1024).decode()   # bytes -> str

"hello".encode() 5 bytes produce karta hai (UTF-8); .decode() ise reverse karta hai. Yeh sabse common beginner error hai.

import socket
c = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
c.sendto(b"ping", ('127.0.0.1', 6000))   # address travels WITH the packet
reply, addr = c.recvfrom(1024)
print(reply.decode())
c.close()

Client par koi connect, koi bind nahi — OS automatically ek ephemeral source port choose kar leta hai, aur destination sendto call mein hi hota hai. Compare karo UDP vs TCP tradeoffs se.

TCP ek byte stream hai — yeh message boundaries preserve nahi karta. Ek single recv(1024) return kar sakta hai:

• b"ABC" (teeno coalesce ho gaye — localhost par sabse common), ya
• b"A", phir baad mein b"BC", ya
• b"AB", phir b"C", ya
• b"A", b"B", b"C" teen recv calls mein. Jo tum kabhi nahi dekhoge woh hai bytes out of order ya missing (TCP order + delivery guarantee karta hai). Bytes hamesha A B C sequence mein aate hain — sirf chunking vary karta hai. Isliye tumhe Message framing / length-prefix protocol chahiye.

UDP message boundaries preserve karta hai lekin delivery ya order ke baare mein kuch guarantee nahi karta:

• Har recvfrom exactly ek poora datagram return karta hai: tum b"A", b"B", b"C" individually paoge — ek call se kabhi b"ABC" nahi milega.
• Lekin inme se koi bhi lost, duplicate, ya reorder ho sakta hai (jaise tum C, A, B padh sakte ho, ya sirf A, C). Boundary-preserving lekin unreliable — TCP ke exact opposite trade. Dekho UDP vs TCP tradeoffs.

TCP mein, recv ka b'' return karna "empty data" nahi hai — yeh EOF hai: peer ne connection close kar diya hai (orderly shutdown). Bina check kiye loop karna zero-length reads par forever spin karta hai. Fix: b'' ko end-of-stream treat karo aur break karo:

while True:
    data = conn.recv(1024)
    if not data:          # b'' -> peer closed
        break
    handle(data)
conn.close()

Scheme: har message = [4-byte length N][N bytes of payload]. Receiver pehle 4 bytes padhta hai, N jaanta hai, phir exactly N aur bytes padhta hai (loop karte hue, kyunki har recv kam return kar sakta hai). Yeh upar figure mein two-step trace se match karta hai. Sender:

import struct
def send_msg(conn, payload: bytes):
    header = struct.pack('>I', len(payload))  # '>I' = big-endian unsigned 4-byte int
    conn.sendall(header + payload)

Receiver — pehle ek robust "read exactly n bytes" helper:

def recv_exact(conn, n):
    buf = b''
    while len(buf) < n:
        chunk = conn.recv(n - len(buf))
        if not chunk:                 # b'' -> peer closed early
            raise ConnectionError("peer closed mid-message")
        buf += chunk
    return buf
 
def recv_msg(conn):
    header = recv_exact(conn, 4)
    (length,) = struct.unpack('>I', header)  # 4 bytes -> int
    return recv_exact(conn, length)

Kyun kaam karta hai: length humein exactly batati hai ki is message mein kitne payload bytes belong karte hain, isliye coalescing/splitting ab humein confuse nahi karti — hum hamesha sahi byte par rukते हैं. Dekho Message framing / length-prefix protocol.

Numeric check (decimal aur hex mein — hex page ke upar introduce ki gayi thi): 300-byte payload ka header struct.pack('>I', 300) hai, jo figure mein dikhaye gaye 4 bytes hain. Plain decimal mein, $300=1\times 256+44$: isliye teesra byte 1 hai aur chautha byte 44 hai. Un chaar byte-values ko hexadecimal mein likhne par (do hex digits per byte) 00 00 01 2C milta hai, kyunki 44 base 16 mein 0x2C hai ($2\times 16+12=44$). Neeche verified hai.

Ek TCP connection close hone ke baad, OS local (IP, port) ko TIME_WAIT state mein ~1–2 minutes ke liye rakhta hai taaki purani connection ke stray late packets catch ho sakein. Us exact port par fresh bind is window ke dauran refuse kar diya jaata hai. Fix — bind se pehle SO_REUSEADDR set karo:

s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 9000))

Yeh OS ko batata hai "ek address jo TIME_WAIT mein stuck hai use reuse karna theek hai." Details: TIME_WAIT and SO_REUSEADDR.

c.connect(('example.com', 80))

connect internally naam ko DNS ke through resolve karta hai (ya tum explicitly socket.gethostbyname('example.com') se kar sakte ho, jo ek IPv4 string return karta hai). DNS woh phone book hai jo human names → IP addresses map karta hai; dekho DNS. Port 80 HTTP ka well-known port hai.

Bahut saare sequentially serve karo: accept + handle ko loop mein wrap karo, aur listening socket ko close mat karo:

while True:
    conn, addr = s.accept()   # blocks for each new client
    data = conn.recv(1024)
    conn.sendall(b"echo: " + data)
    conn.close()              # close the per-client socket, keep s open

Threads ke bina bahut saare concurrently serve karo: ek event loop use karo jo bahut saare sockets watch kare aur sirf ready wale par wake kare — select ya asyncio. Ek process, bahut saare live conns, koi blocking accept show monopolize nahi karta. Dekho select / asyncio for concurrent servers. Key insight: listening socket s aur har connection socket conn alag objects hain — yahi separation ek server ko clients multiplex karne deta hai.

Haan — ek zero-length UDP datagram ek real, valid packet hai. Server ka recvfrom(1024) unblock hota hai aur (b'', addr) return karta hai: empty payload, lekin ek real sender address. TCP se compare karo, jahan recv ka b'' return karna matlab hai peer ne connection close kar diya. UDP mein b'' ka matlab sirf "ek empty postcard aaya" — close karne ke liye koi connection nahi hai. Same-looking value, opposite meaning: yeh ek favourite exam trap hai.

TCP three-way handshake se connection setup karta hai: SYN → SYN-ACK → ACK = koi bhi data se pehle 3 messages. Isliye TCP ek "phone call" hai (dial, ring, pick up). Dekho TCP three-way handshake. UDP connectionless hai: koi handshake nahi, isliye client ka pehla sendto already data carry karta hai — 0 setup round-trips. Wahi saved latency exactly reason hai DNS, gaming, aur voice UDP use karte hain (UDP vs TCP tradeoffs).

Page ke upar backlog definition yaad karo: yeh us chhoti "waiting bench" ki size hai connections ki jo connecting finish kar chuki hain lekin abhi accept nahi hui hain. Isliye 5 us queue ko bound karta hai — zyada se zyada 5 completed-but-unaccepted connections wait kar sakti hain. 6th ka kya hota hai? Agar 6th client apna connection complete karta hai jab queue already full hai aur server ne use accept se drain nahi kiya hai, toh OS us connection ko refuse ya drop kar sakta hai. Client phir ek connection error dekhta hai (ya uska TCP stack silently retry karta hai). Important: backlog total ya concurrent clients limit nahi karta — yeh sirf bursts ke liye ek buffer hai. Jab tak tumhara server accept call karta raha, bench empty hoti rahegi aur naye clients succeed karte rahenge. Actually bahut saare clients serve karne ke liye tum apna accept-loop / concurrency model fix karte ho (Exercise 5.1), yeh number nahi.

Calls ka naam lo (L1) → unhe order mein bytes not str ke saath likho (L2) → predict karo ki TCP streams / UDP datagrams alag behave karte hain (L3) → framing + port reuse + DNS banao (L4) → concurrency, EOF, handshakes, backlog ke baare mein reason karo (L5).