Visual walkthrough — Socket programming — TCP server - client, UDP server - client in Python

4.3.28 · D2 · Coding › Computer Networks › Socket programming — TCP server - client, UDP server - clien

Hum sirf numbers ki ek row se shuru karte hain. Har symbol use hone se pehle earn kiya jaata hai.

Step 1 — "Byte" kya hota hai, aur "sending" ka matlab kya hai

KYA HAI. Ek byte bas ek chota sa pura number hota hai $0$ aur $255$ ke beech. Bas itna hi. Letter A byte $65$ ke roop mein store hota hai; B $66$ hai; C $67$ hai. Jab aapka program "text send" karta hai, woh actually in chote numbers ki ek line ko aapke computer mein ek hole se bahar dhakelta hai jise socket kehte hain (endpoint from parent idea of IP + port).

YAHAN SE KYUN SHURU KAREIN. Saari TCP-vs-UDP ki confusion isi wajah se aati hai kyunki hum bhool jaate hain ki network numbers move karta hai, words nahin. Agar hum bytes ko beads ki tarah picture karein, toh baaki sab obvious ho jaata hai.

PICTURE. Figure dekho: teen letters teen chote red numbers ban jaate hain, phir beads ki ek seedhi line right taraf socket mein flow karti hai. Beads ke beech abhi koi wall nahin hai — yeh yaad rakho.

Step 2 — Woh ek difference jo sab kuch badal deta hai: boundary vs no boundary

KYA HAI. Network aapke beads do tareekon se carry kar sakta hai:

• Beads ko labelled bags mein rakho — bag 1 = [65], bag 2 = [66], bag 3 = [67]. Receiver ek ek bag kholti hai. Yeh ek datagram hai — UDP ki unit.
• Saare beads ek lambe conveyor belt par daalo — [65, 66, 67, ...] bina kisi divider ke. Receiver "kuch beads" scoop karta hai lekin usse koi idea nahin hota ki ek send kahan khatam hua aur agla kahan shuru hua. Yeh ek stream hai — TCP ki unit.

YEH THE picture kyun hai. Parent note ka almost har socket bug ("one send ≠ one recv") asal mein "Maine socha bags hain lekin belt thi" hi hai. Jab ek baar belt dikh jaati hai, bug obvious hota hai, surprising nahin.

PICTURE. Top row (red bags) = UDP: teen sealed packets. Bottom row = TCP: ek uninterrupted red belt usi data ki. Same data, different packaging.

Step 3 — UDP close se: sendto ek bag seal karta hai, recvfrom exactly ek kholta hai

KYA HAI. UDP mein har sendto(data, addr) ek bag seal karta hai aur bahar destination likhta hai. Har recvfrom(1024) exactly ek bag kholta hai aur return address bata deta hai. Teen sends → teen tak receives, har ek ek poora message.

sendto/recvfrom kyun, send/recv nahin? Kyunki koi setup call nahin hoti (koi handshake nahin), address har bag ke saath hona chahiye. Toh call khud address carry karti hai — literally isliye UDP yeh do naam use karta hai (parent ke "Why no listen/accept" note se).

PICTURE. Teen red bags sendto se left par nikalta dekhte hain aur right par ek per recvfrom pop out hote hain. Green count "3 in → 3 out" sirf tabhi hold karta hai agar kuch lost nahin hua — loss Step 6 mein handle karte hain.

Step 4 — TCP close se: send beads daalta hai, recv beads scoop karta hai

KYA HAI. TCP mein, sendall(b"A"), sendall(b"B"), sendall(b"C") beads $65,66,67$ belt par dalte hain. Doosri taraf recv(1024) sirf yeh kehta hai: "mujhe abhi jo bhi 1024 beads ready hain woh de do." Woh b"ABC" (teeno, coalesced) ya b"A" phir b"BC" (split) return kar sakta hai. Aap control nahin kar sakte yeh.

YEH KYUN HOTA HAI? OS beads ko efficiency ke liye batch karta hai, aur network unhe kisi bhi size ke chunks mein deliver kar sakta hai. TCP mein kuch bhi record nahin hota "yahan ek send khatam hua". Belt mein koi walls nahin hain (Step 1 ki warning pay off hoti hai).

PICTURE. Teen colored sends belt mein enter karte hain; right par ek single recv ek red lump "ABC" scoop karta hai. Dashed lines jo dikhate hain har send pehle kahan begin hoti thi woh grey aur ghostly hain — receiver unhe dekh nahin sakta.

Step 5 — Fix: belt par apni khud ki walls wapas daalo (framing)

KYA HAI. Agar TCP boundaries nahin rakhega, toh hum unhe add karte hain. Classic trick: har message se pehle uski length ek fixed-size header ke roop mein likho, phir bytes. Padhne ke liye: pehle length $n$ padho, phir tab tak scooping karte raho jab tak exactly $n$ beads na ho jaayein.

LENGTH PREFIX KYUN, "\n" jaisa delimiter kyun nahin? Delimiter tab toot jaata hai jab message khud woh character contain kare; length number kabhi "accident se" payload ke andar nahin aata kyunki hum pehle fixed count padhte hain. Yeh length-prefix protocol hai.

PICTURE. Step 4 ki same belt, lekin ab har message se pehle ek chota red box hai jisme uski length hai ($1,1,1$). Reader un boxes ko saw-cuts ki tarah use karta hai belt ko wapas A, B, C mein slice karne ke liye.

Step 6 — Edge & degenerate cases (jo exams love karte hain)

Har scenario jo reader ko mil sakta hai, har ek ka apna panel figure mein:

Case A — TCP recv b'' (empty) return karta hai. Yeh nahin hai "abhi koi data nahin"; yeh EOF hai: peer ne close call kiya. Belt switch off ho gayi hai. Apna loop band karo.

Case B — UDP datagram lost ho jaata hai. Ek bag truck se gir jaata hai. UDP kisi ko nahin batata. "3 in" "2 out" ban sakta hai. Agar aapko reliability chahiye toh aap khud sequence numbers/acks add karo (dekho UDP vs TCP tradeoffs).

Case C — UDP datagrams reorder ho jaate hain. Bags A, B, C A, C, B aa sakte hain. Network har bag ko independently reroute karne ke liye free hai. Sirf aapke khud ke sequence numbers order restore kar sakte hain.

Case D — TCP send data ka part bhejta hai. send sirf kuch beads push kar sakta hai; sendall tab tak loop karta hai jab tak har bead belt par na ho. sendall use karo jab tak aapko counts track karna enjoy na ho.

Case E — zero-length UDP send. sendto(b"", addr) ek legal, empty lekin real datagram hai; recvfrom (b"", addr) return karta hai. Yahan empty ka matlab hai "ek empty bag aaya", EOF nahin — Case A ka ulta. Yeh asymmetry sabko trip karti hai.

Ek picture summary

Upar sab kuch ek canvas par: bytes beads ban jaate hain (Step 1); UDP unhe bag karta hai aur boundaries rakhta hai (Steps 3), TCP unhe ek wall-less belt par daalta hai toh messages merge ho jaate hain (Step 4); hum belt ko length headers se frames mein kaat dete hain (Step 5); aur edge cases — EOF, loss, reorder, empty datagram — sides par latke hain (Step 6).

Khud test karo