- जैसे NetworkManager थोड़ी देर की connection instability को “नेटवर्क नहीं है” मान लेता है, वैसे ही कुछ software TCP recovery से ज्यादा अपने status judgment पर भरोसा करते हैं, लेकिन वास्तविक networks में यह जोखिम भरा हो सकता है
- “भेजा गया data पहुंचता है”, “दोनों पक्ष अंततः delivered bytes पर सहमत हो जाते हैं”, “HTTP या SMTP जैसे application protocol से guarantee दी जा सकती है” जैसी धारणाएं कुछ स्थितियों में टूट जाती हैं
- ACK processing के दौरान connection टूट जाए, तो sender यह नहीं जान सकता कि segment receive हुआ या नहीं; और यह सीमा Two Generals’ Problem की तरह केवल एक two-party TCP stream से हल नहीं होती
- SMTP भी RFC 1047 और RFC 2821 में इस समस्या को संबोधित करता है; delivery responsibility transfer होने के क्षण पर connection failure होने पर duplicate transmission या omission की ambiguous zone बन सकती है
- अजीब networks को exception मानना, या Nagle algorithm, congestion control, ICMP blocking जैसी detailed behaviours को ignore करना, real failures की गलत interpretation करा सकता है
TCP से पहले network status पर निष्कर्ष निकालने की समस्या
- NetworkManager इस्तेमाल करने वाले एक user ने पहले dormitory और campus roaming environment में wireless connection instability झेली थी, और थोड़ा सा packet loss होते ही पूरे system को “नेटवर्क नहीं है” signal मिलते देखा था
- उस समय network के जल्द लौट आने की संभावना थी, और सामान्य TCP recovery latency में बड़े spike के साथ भी applications को transparent दिख सकती थी
- यह case उस समस्या से जुड़ता है जहां applications या system components, TCP द्वारा संभाले जा सकने वाले temporary failure को बहुत जल्दी failure मान लेते हैं
TCP के बारे में आम तौर पर गलत मानी जाने वाली बातें
- TCP से deal करते समय ये statements अक्सर सुनने को मिलते हैं, लेकिन प्रत्येक कम-से-कम कुछ cases में गलत है
- TCP reliable है, इसलिए भेजा गया सारा data दूसरे पक्ष तक पहुंचता है
- TCP broadly reliable है
- भले ही TCP पूर्ण अर्थ में reliability न दे, sender और receiver अंततः इस पर exactly सहमत हो जाते हैं कि कौन-से bytes transmit हुए
- TCP के ऊपर HTTP या SMTP जैसे message-oriented application protocol बनाने से ऐसी guarantee बनाई जा सकती है
- TCP packet जैसी कोई चीज होती है
- TCP packet जैसी कोई चीज नहीं होती
- किसी जाने-माने remote host से connect न कर पाएं, तो आप offline हैं
- Nagle algorithm अच्छा है
- Nagle algorithm खराब है
- Nagle algorithm की परवाह करने की जरूरत नहीं है
- TCP को network से गुजरने वाली bidirectional Unix pipe की तरह सोचना काफी है
- अगर network TCP के लिए transparent है, तो IP के लिए भी transparent है
- अगर network HTTP/1.1 के लिए transparent है, तो TCP के लिए भी transparent है
- standard protocols के लिए transparent न होने वाले अजीब networks exceptional हैं, इसलिए ignore किए जा सकते हैं
- TCP, IP के ऊपर implement होता है
delivered bytes पर exactly सहमति बनाना मुश्किल क्यों है
- TCP reliability से जुड़े ऊपर के 1–4 मुद्दे Two Generals’ Problem से जुड़े हैं
- अगर ACK अभी process हो रहा हो और connection टूट जाए, तो sender के पास यह confirm करने का तरीका नहीं होता कि संबंधित segment receive हुआ या नहीं
- TCP के ऊपर complex layers और जोड़ देने से भी यह सीमा गायब नहीं होती
- एक single two-party TCP stream पर यह guarantee नहीं बनाई जा सकती; ऐसी guarantee के लिए Paxos या Raft जैसी approach और कम-से-कम 3 nodes चाहिए
- इसी तरह की समस्या सिर्फ TCP ही नहीं, UDP या IP-based two-party services पर भी लागू होती है
SMTP में दिखने वाला delivery responsibility का gray area
- SMTP ऐसी service है जिसमें दोनों पक्षों को explicitly यह ध्यान रखना पड़ता है कि message receive हुआ या नहीं, इसलिए यह समस्या साफ दिखती है
- RFC 1047 इस समस्या को SMTP के perspective से address करता है, और RFC 2821 तय करता है कि implementations को RFC 1047 की core advice follow करनी चाहिए
- SMTP example में ये states अलग-अलग मानी जाती हैं
- ऐसे point तक पहुंचा जा सकता है जहां दोनों पक्ष सहमत हों कि email client से server को transmit हो गया
- ऐसे point तक भी पहुंचा जा सकता है जहां दोनों पक्ष सहमत हों कि server ने email delivery responsibility ले ली है
- लेकिन उससे पहले अनिवार्य रूप से ऐसी ambiguous state से गुजरना पड़ता है जहां यह स्पष्ट नहीं होता कि इस समय email delivery responsibility किसकी है
- इस ambiguous state में connection टूट जाए, तो email duplicate हो सकती है या miss हो सकती है
- SMTP specification यह तय करती है कि email को duplicate करने वाला पक्ष कौन होगा, लेकिन वास्तविक implementations में इसकी कितनी testing हुई है, यह पता नहीं
- Paxos और Raft का उद्देश्य final state हासिल करने से ज्यादा, ऐसी ambiguous states को रोकना है
two-party consensus में बची रहने वाली knowledge की सीमाएं
- एक comment मानता है कि unreliable लेकिन malicious न होने वाले link पर भी दो parties कुछ bytes के set के बारे में यह सहमति बना सकती हैं कि “वे delivered हुए हैं और दोनों पक्ष यह fact जानते हैं”
- आगे की discussion में यह निष्कर्ष निकला कि एक party यह जान सकती है कि agreed set में कम-से-कम पहले N bytes शामिल हैं, लेकिन यह नहीं जान सकती कि agreed set exactly पहले N bytes ही है
- इसलिए “पक्का delivered हुए और दोनों पक्ष जानते हैं” वाला bytes set मौजूद हो सकता है, लेकिन उसके बाद ऐसा gray area बचता है जहां sender और receiver एक-दूसरे की knowledge state तय नहीं कर सकते
- इस अंतर को न समझने पर distributed systems में अजीब failures होना आसान है
real networks और lower layers के traps
- “standard protocols के लिए transparent न होने वाले अजीब networks को ignore किया जा सकता है” वाली धारणा कई बार problems का कारण बनी है
- buffer bloat को ऐसे case के रूप में लिया गया है जहां router congestion control mechanism को तोड़ देता है
- ICMP block करने वाले या न समझ आने वाले traffic को drop करने वाले networks भी problem बन सकते हैं
- “congestion control जानने की जरूरत नहीं” वाली धारणा भी TCP को गलत समझने के case जैसी है
- lower example के तौर पर “desired speed न मिले तो कई TCP connections खोल लो” वाला विचार आता है
अभी कोई टिप्पणी नहीं है.