UDP और TCP

कच्चे UDP और TCP की अपनी कोई स्क्रीन नहीं है। इनका उपयोग आप ऐसे डिवाइस के लिए करते हैं जिसका अपना टेक्स्ट या बाइनरी प्रोटोकॉल हो — कोई प्रोजेक्टर, मीडिया सर्वर, सेंसर — और ये कई जगह आते हैं:

के लिए…	उपयोग करें
चरण के रूप में डेटाग्राम या TCP संदेश भेजना, और जवाब की प्रतीक्षा करना	प्रयोग के चरण
फिर भेजने के लिए डेटाग्राम रखना, या जो कैप्चर किया उसे फिर चलाना	एक UDP सिग्नल
स्क्रिप्ट से एक डेटाग्राम भेजना	signallab send udp
एक साथ कई होस्ट को, ब्रॉडकास्ट पते पर या मल्टीकास्ट समूह पर भेजना	ब्रॉडकास्ट स्क्रीन
किसी सर्वर या लिंक पर ट्रैफ़िक का लोड डालना	Storm
पता करना कि किसी होस्ट के कौन-से TCP पोर्ट खुले हैं	Scanner
डिवाइस का पक्ष निभाना	कोई UDP या TCP डिवाइस एमुलेटर
दो सिरों के बीच नेटवर्क को बिगाड़ना	एक इम्पेयरमेंट रिले

OSC एक ऐसा फ़ॉर्मैट है जो UDP डेटाग्राम में ले जाया जाता है; उसका अपना पेज है: OSC।

पेलोड

जहाँ भी आप कोई कच्चा पेलोड लिखते हैं, वह दो तरह का होता है:

प्रकार	क्या भेजा जाता है	उदाहरण
टेक्स्ट	अक्षर UTF-8 के रूप में, ठीक वैसे जैसे टाइप किए गए: कोई टर्मिनेटर नहीं, कोई लाइन अंत नहीं जोड़ा जाता। एक लाइन प्रोटोकॉल को अपना लाइन अंत टेक्स्ट में चाहिए।	PING
Hex बाइट	बाइट दर बाइट, hex अंकों के जोड़ों में लिखा हुआ। जोड़ों के बीच स्पेस, :, - और , तथा उनसे पहले 0x की अनुमति है।	de ad be ef, DEADBEEF, 0xde,0xad

एक डेटाग्राम अधिकतम 65 507 बाइट ले जाता है। विषम संख्या में hex अंक, या कोई भी नहीं, कुछ भेजे जाने से पहले त्रुटि है।

INFO

UDP के पास पहुँचने की कोई रसीद नहीं है। "भेजा गया" का अर्थ है कि डेटाग्राम इस मशीन से चला गया, यह नहीं कि किसी ने उसे पाया। यह जानने के लिए कि किसी डिवाइस ने आपको सुना, उसके जवाब की प्रतीक्षा करें।

यह कहाँ जाता है

कोई गंतव्य एक IP पता और एक पोर्ट होता है, या एक होस्ट नाम और एक पोर्ट: 192.0.2.20:9000, [2001:db8::20]:9000 (IPv6 पता कोष्ठकों में जाता है), projector.local:9000। यह UDP चरण के लक्ष्य, किसी OSC लक्ष्य, किसी UDP सिग्नल, signallab send udp और signallab send osc, ब्रॉडकास्ट सूची, Storm के लक्ष्य और TCP चरण के होस्ट पर लागू होता है।

होस्ट नाम हर बार उपयोग होने पर खोजा जाता है। जब उसका कोई IPv4 पता होता है, तो वही उपयोग होता है — इसलिए localhost 127.0.0.1 पर सुनने वाली सेवा तक पहुँचता है, जहाँ कोई सिस्टम उसके लिए जो पहला पता सूचीबद्ध करता है वह ::1 हो सकता है — और जिस नाम के केवल IPv6 पते हों, उस तक IPv6 सॉकेट से पहुँचा जाता है। जो नाम रिज़ॉल्व नहीं होता, वह Cannot resolve … के साथ विफल होता है; पोर्ट के बिना गंतव्य, या जो इन दोनों में से कोई रूप न हो, … is not a valid address के साथ। जिन पतों पर कोई सेवा सुनती है (मॉनिटर का, किसी wait का, किसी एमुलेटर का), वे हमेशा IP:port होते हैं।

प्रयोगों में

चरण	क्या करता है
UDP डेटाग्राम	अपना पेलोड लक्ष्य host:port पर टेक्स्ट के रूप में भेजता है। लक्ष्य IP:port या host:port होता है (ऊपर), और कॉमा से अलग किए कई लक्ष्यों में से हर एक को डेटाग्राम मिलता है। जवाब की प्रतीक्षा करें के साथ यह जवाब का पोर्ट (IP:port) से भेजता है और उसी चरण में वहीं जवाब की प्रतीक्षा करता है। विवरण
UDP की प्रतीक्षा	सुनने का पता (IP:port) (IP:port) पर सुनता है और ऐसे डेटाग्राम की प्रतीक्षा करता है जिसका पेलोड मेल खाता हो। विवरण
TCP संदेश	होस्ट और पोर्ट से कनेक्ट होता है, अपना पेलोड टेक्स्ट के रूप में लिखता है, जवाब के लिए 250 ms सुनता है, और बंद कर देता है। चरण बताता है कि कितने बाइट वापस आए, यह नहीं कि वे क्या थे। विवरण

UDP पेलोड और लक्ष्य, TCP होस्ट और पेलोड, तथा किसी wait का पैटर्न {{templates}} लेते हैं, इसलिए कोई डेटाग्राम रन की id या पिछले चरण के निकाले किसी मान को ले जा सकता है। देखें डेटा और टेम्पलेट।

डेटाग्राम का मिलान

UDP की प्रतीक्षा और UDP डेटाग्राम का जवाब किसी डेटाग्राम को उसके पेलोड से चुनते हैं:

पेलोड	डेटाग्राम कब लेता है
कोई भी डेटाग्राम	हमेशा: पहला जो आता है
टेक्स्ट शामिल है	उसका पेलोड, टेक्स्ट के रूप में पढ़ा गया, पैटर्न समाहित करता है
regex से मेल खाता है	उसका पेलोड, टेक्स्ट के रूप में पढ़ा गया, रेगुलर एक्सप्रेशन से मेल खाता है
बाइट शामिल हैं (hex)	उसकी बाइट में पैटर्न की बाइट होती है, जो hex में लिखी गई है

जो मेल खाया वह चरण के वेरिएबल में रखा जाता है (जवाब का वैरिएबल, reply जब तक आप उसका नाम न बदलें): text, hex (पहले 1024 बाइट), bytes (आकार), from (भेजने वाले का IP:port), ms (कितना समय लगा) और match (जो टेक्स्ट या बाइट मिले, या किसी रेगुलर एक्सप्रेशन का पहला समूह)।

एक wait रन के शुरू होने पर सुनना शुरू करता है, चरण तक पहुँचने पर नहीं, इसलिए बहुत तेज़ी से आने वाला जवाब छूटता नहीं। यह केवल वही लेता है जो उसके पथ पर अंतिम भेजने के बाद आया।

सीमाएँ और डिफ़ॉल्ट

सेटिंग	डिफ़ॉल्ट	श्रेणी
TCP चरण: टाइमआउट (ms) (कनेक्ट होना, लिखना और जवाब, सब मिलाकर)	4000 ms	1–120 000 ms
किसी wait या जवाब का टाइमआउट, ms	2000 ms	1–120 000 ms
UDP पेलोड	—	अधिकतम 65 507 बाइट
सुनने का पता	—	पोर्ट के साथ IP:port; किसी जवाब का जवाब का पोर्ट (IP:port) पोर्ट 0 (कोई भी ख़ाली पोर्ट) उपयोग कर सकता है

इंस्पेक्टर में, UDP चरण का डेटाग्राम स्रोत broadcast के साथ दिखता है (या experiment जब चरण जवाब की प्रतीक्षा करता है), और किसी wait के पोर्ट पर आने वाला हर डेटाग्राम स्रोत experiment-wait के साथ। एक TCP चरण स्रोत experiment के साथ दो tcp फ़्रेम के रूप में दिखता है: जो पेलोड उसने लिखा और, जब कोई आया, जो जवाब उसने पढ़ा। उसकी टाइमलाइन प्रविष्टि बताती है कि उसने क्या भेजा और जवाब कितना बड़ा था।

सिग्नल

लाइब्रेरी में एक UDP (रॉ) सिग्नल एक लक्ष्य और एक पेलोड होता है, टेक्स्ट या hex बाइट के रूप में। इसे सिग्नल से, या किसी भी स्क्रीन पर Ctrl+K से भेजें। इसका लक्ष्य कोई होस्ट नाम हो सकता है।

इंस्पेक्टर ने जो भी डेटाग्राम पूरा रखा हो, वह एक बन सकता है: सिग्नल के रूप में सहेजेंकैप्चर किए गए फ़ोल्डर में एक hex UDP सिग्नल बनाता है, जो ठीक वही बाइट फिर चलाता है — भेजे गए फ़्रेम के लिए फ़्रेम के गंतव्य को, आए हुए के लिए उस पते को जिसने उसे प्राप्त किया (इस कंप्यूटर पर, जब वह हर पता था)। TCP का टुकड़ा ऐसा नहीं बन सकता: वह एक स्ट्रीम का हिस्सा है। देखें सिग्नल और इंस्पेक्टर।

टेक्स्ट UDP सिग्नल किसी प्रयोग में UDP डेटाग्राम चरण के रूप में जोड़ा जा सकता है; hex वाला नहीं, क्योंकि चरण टेक्स्ट भेजता है।

कमांड लाइन से

signallab send udp एक डेटाग्राम भेजता है:

signallab send udp 127.0.0.1:9000 --text "PING"
signallab send udp 127.0.0.1:9000 --hex "de ad be ef"

✔ sent 4 bytes → 127.0.0.1:9000

--text और --hex में से ठीक एक दें। लक्ष्य IP:port या host:port होता है (ऊपर)। यह 0 के साथ निकलता है जब डेटाग्राम चला गया, 1 जब भेजना विफल हुआ, और 2 जब लक्ष्य या hex अमान्य हो। कोई send tcp नहीं है। देखें कमांड लाइन।

Storm

स्टॉर्म आपके अपने सर्वरों और लिंक के लिए एक लोड स्रोत है: एक UDP फ़्लड तय आकार के डेटाग्राम तय दर पर भेजता है, एक TCP कनेक्ट फ़्लड कनेक्शन खोलता है, पेलोड लिखता है और बंद करता है, बार-बार। थ्रूपुट लाइव मापा जाता है। देखें Storm।

Scanner

स्कैनर किसी श्रेणी के हर पोर्ट से TCP कनेक्शन की कोशिश करता है और जो स्वीकार करते हैं उन्हें सूचीबद्ध करता है, और अगर आप बैनर माँगें तो सेवा जो पहले कहती है वह भी। देखें Scanner।

DANGER

Storm और Scanner असली होस्टों को असली ट्रैफ़िक भेजते हैं। इन्हें केवल उन सिस्टमों की ओर मोड़ें जो आपके हैं या जिन्हें परखने की आपको अनुमति है: एक storm किसी लिंक को भर सकता है, और दोनों intrusion detection को ट्रिगर कर सकते हैं।

एमुलेट किए गए डिवाइस

एमुलेटर स्क्रीन पर Signal Lab ख़ुद डिवाइस बन सकता है:

• एक UDP डिवाइस डेटाग्राम का जवाब उनके पेलोड पर नियमों से देता है — कोई भी, कोई टेक्स्ट समाहित, किसी रेगुलर एक्सप्रेशन से मेल, कुछ बाइट समाहित — जो आया उससे बना टेक्स्ट या hex जवाब, भेजने वाले को या किसी और IP:port को, और अगर आप कोई विलंब सेट करें तो उसके बाद;
• एक TCP डिवाइस कनेक्शन स्वीकार करता है, जो आता है उसे आपके चुने लाइन अंत (LF, CR LF, CR, या हर चंक जैसे आता है) पर संदेशों में बाँटता है, हर एक का जवाब उसी तरह के नियमों से देता है, क्लाइंट के कनेक्ट होते ही अभिवादन भेज सकता है, और किसी जवाब के बाद कनेक्शन बंद कर सकता है।

दोनों एक रन की अवधि के लिए एमुलेटर चरण के रूप में भी चल सकते हैं। देखें एमुलेटर।

इम्पेयरमेंट

बाधा रिले किसी क्लाइंट और उसके लक्ष्य के बीच बैठता है और जो गुज़रता है उसे बिगाड़ता है: UDP पर प्रति डेटाग्राम (विलंब, हानि, प्रतिलिपियाँ, पुनःक्रमण, बैंडविड्थ सीमा) या TCP पर प्रति स्ट्रीम (विलंब, बैंडविड्थ सीमा, कनेक्शन रीसेट या आधे-खुले छोड़े गए)। देखें इम्पेयरमेंट और, किसी प्रयोग के भीतर, फ़ॉल्ट।

Windows पर "Port unreachable"

जब कोई डेटाग्राम ऐसे पोर्ट पर पहुँचता है जहाँ कुछ नहीं सुनता, तो प्राप्त करने वाली मशीन आमतौर पर ICMP "port unreachable" संदेश से जवाब देती है। Windows उस जवाब की सूचना भेजने वाले सॉकेट के अगले receive पर देता है, मानो कनेक्शन रीसेट हो गया हो — भले ही UDP का कोई कनेक्शन नहीं होता।

Signal Lab इसकी अपेक्षा करता है। इसके listeners — OSC मॉनिटर, discovery listener, प्रयोग के waits और जवाब, UDP और OSC एमुलेटर, इम्पेयरमेंट रिले — इसे दर्ज करते हैं और सुनते रहते हैं। जो डिवाइस चला गया है वह उन्हें नहीं रोकता। जो listener सचमुच और प्राप्त नहीं कर सकता, वह अपना जॉब समाप्त कर देता है, और कंसोल कारण बताता है।

समस्याएँ

जो आप देखते हैं	सामान्य कारण
… is not a valid address	लक्ष्य में पोर्ट नहीं है, या वह न IP:port है न host:port।
Cannot resolve …	होस्ट नाम इस मशीन पर रिज़ॉल्व नहीं होता।
… refused the connection — nothing is listening on that port (TCP)	उस पोर्ट पर कुछ नहीं सुनता, या कोई फ़ायरवॉल उसे अस्वीकार करता है।
No answer from … in time (TCP)	होस्ट बिल्कुल जवाब नहीं देता — ग़लत पता, या ऐसा फ़ायरवॉल जो अस्वीकार करने के बजाय गिरा देता है।
डिवाइस जवाब देता है फिर भी कोई wait टाइमआउट हो जाता है	डिवाइस उस पोर्ट को जवाब देता है जिससे डेटाग्राम आया, wait के पोर्ट को नहीं। भेजने को जवाब की प्रतीक्षा करें के साथ ख़ुद जवाब की प्रतीक्षा करने दें: तब वह उसी पोर्ट से जाता है जिस पर जवाब वापस आता है।
दूसरी मशीनों से डेटाग्राम कभी नहीं आते	Windows पर फ़ायरवॉल उन्हें रोक सकता है: जब ऐप पेशकश करे तो Signal Lab को अनुमति दें। देखें समस्या निवारण।

हर त्रुटि संदेश त्रुटि संदेश में सूचीबद्ध है।