एमुलेटर

एमुलेटर में Signal Lab उस API, डिवाइस या सेवा की भूमिका निभाता है जिससे आपका सिस्टम बात करता है। यह एक पते पर सुनता है और नियमों से जवाब देता है: HTTP API रूट के ज़रिए, OSC, UDP या TCP डिवाइस “यह आए तो वह जवाब दो” के ज़रिए, और MQTT ब्रोकर किसी भी ब्रोकर की तरह, साथ में अपने नियमों के साथ। यह धीमा हो सकता है, विफल हो सकता है, या बीच-बीच में बंद हो सकता है, ताकि आप टेस्ट कर सकें कि अपनी डिपेंडेंसी के गड़बड़ करने पर आपका सिस्टम क्या करता है। हर आदान-प्रदान गिना जाता है, सूची में आता है और इंस्पेक्टर में भेजा जाता है।

एमुलेटर एक दस्तावेज़ है। एमुलेटर स्क्रीन इनकी एक लाइब्रेरी रखती है; वही दस्तावेज़ किसी प्रयोग के भीतर एमुलेटर नोड के रूप में, कमांड लाइन से signallab emulate के साथ, और API तथा MCP के ज़रिए चलता है, और हर जगह एक ही तरह जवाब देता है।

स्क्रीन

बाईं ओर लाइब्रेरी (लाइब्रेरी) है: हर एमुलेटर अपने प्रोटोकॉल और पते के साथ, और चल रहे एमुलेटर पर धड़कता बिंदु और रिक्वेस्ट की गिनती। दाईं ओर चुने गए एमुलेटर की सेटिंग्स और नियम हैं, और उनके नीचे वह जो उसे प्राप्त हुआ (लाइव)।

एमुलेटर बनाना

लाइब्रेरी के ऊपर के बटनों में से एक दबाएँ:

बटन	क्या बनाता है	कहाँ सुनता है	एक नियम के साथ, जो जैसा है वैसा ही काम करता है
＋ HTTP API	HTTP API	`127.0.0.1:18080`	`GET /health` → 200 `{"status":"ok"}`
＋ OSC डिवाइस	OSC डिवाइस	`127.0.0.1:9100`	`/ping` → `/pong`, गिनती int के रूप में
＋ UDP डिवाइस	UDP डिवाइस	`127.0.0.1:7100`	`PING` वाला डेटाग्राम → `PONG 1`, `PONG 2`, …
＋ TCP डिवाइस	TCP डिवाइस	`127.0.0.1:7200`	`PING` वाली पंक्ति → `PONG`
＋ MQTT ब्रोकर	MQTT ब्रोकर	`127.0.0.1:1883`	`lab/<name>/set` पर पब्लिश → वही पेलोड, retained, `lab/<name>/state` पर

अगर लाइब्रेरी का कोई दूसरा एमुलेटर वह पोर्ट पहले से उपयोग करता है, तो अगला ख़ाली पोर्ट लिया जाता है।

इसे नाम दें (अधिकतम 120 अक्षर)।
सुनने का पता सेट करें: IP:port। 127.0.0.1 केवल इसी कंप्यूटर को जवाब देता है; 0.0.0.0 नेटवर्क को भी।
नियम बदलें (नीचे देखें), और नोट में लिखें कि यह किसकी जगह ले रहा है।

बदलाव अपने आप सहेजे जाते हैं। डुप्लिकेट करें अगले ख़ाली पोर्ट पर एक कॉपी बनाता है। हटाएँ एक बार और पूछता है (हटाएँ?), एमुलेटर चल रहा हो तो उसे रोकता है, और उसे लाइब्रेरी से हटा देता है।

नियम क्रम से, पहले से अंतिम तक, आज़माए जाते हैं; जो पहला मेल खाता है, वही जवाब देता है। हर नियम के हेडर में एक पंक्ति का सारांश दिखता है; नियम खोलने या समेटने के लिए उस पर क्लिक करें। ↑ और ↓ बटन नियम को ऊपर-नीचे करते हैं, × उसे हटाता है।

इसे चलाना

एमुलेटर चुनें और शुरू करें दबाएँ। बटन के लौटने से पहले उसका पोर्ट खुल जाता है: पहले से लिया गया पोर्ट, या किसी समस्या वाला एमुलेटर, वहीं वजह के साथ अस्वीकार कर दिया जाता है।
अपने सिस्टम को इसकी ओर मोड़ें। HTTP API के लिए URL कॉपी करें उसका पता (http://127.0.0.1:18080) कॉपी करता है, और हर रूट का अपना पता कॉपी करने के लिए एक URL कॉपी करें बटन होता है (तब नहीं, जब उसके पाथ में {{…}} टेम्पलेट हो)।
प्राप्त को भरते देखें।
रोकें दबाएँ, या कंसोल पट्टी से इसका जॉब रोकें।

बटनों के पास की स्थिति बताती है: नहीं चल रहा, यह कहाँ जवाब देता है, या यह कि यह बंद है।

एमुलेटर उन्हीं नियमों से जवाब देता रहता है जिनके साथ उसे शुरू किया गया था। चलते समय उसे बदलने पर रीस्टार्ट करें दिखता है: नियम अब जैसे हैं, उनके साथ फिर से शुरू करने के लिए इसे दबाएँ। तब तक नियमों पर मिलान की गिनती छिपी रहती है, क्योंकि वह पुराने नियमों की है।

बंद करें चल रहे एमुलेटर को तब तक अनुपलब्ध कर देता है, जब तक आप चालू करें न दबाएँ: HTTP रिक्वेस्ट को 503 मिलता है, TCP डिवाइस और MQTT ब्रोकर अपने कनेक्शन तोड़ देते हैं और नए अस्वीकार करते हैं, OSC या UDP डिवाइस कोई जवाब नहीं देता। देखें बंद होना।

एक ही ट्रांसपोर्ट के दो एमुलेटर एक पोर्ट साझा नहीं कर सकते: HTTP, TCP और MQTT एमुलेटर TCP पोर्ट पर सुनते हैं, OSC और UDP एमुलेटर UDP पोर्ट पर। HTTP API और OSC डिवाइस दोनों पोर्ट 8080 उपयोग कर सकते हैं; दो HTTP API नहीं। लिए गए पोर्ट पर दूसरा एमुलेटर शुरू होते समय अस्वीकार कर दिया जाता है।

TIP

सर्वर से जुड़े ब्राउज़र में एमुलेटर सर्वर पर चलता है। 0.0.0.0 पर सुनने वाले एमुलेटर तक सर्वर के नाम से पहुँचा जाता है, और URL कॉपी करें वही पता कॉपी करता है; 127.0.0.1 वाला केवल सर्वर पर ही चल रहे प्रोग्राम को जवाब देता है।

क्या आया

चलते समय लाइव गिनता है:

गिनती	क्या
रिक्वेस्ट	जो कुछ भी आया: रिक्वेस्ट, संदेश, पंक्तियाँ।
कोई नियम नहीं	जिसे किसी नियम ने नहीं लिया। बिना रूट वाली HTTP रिक्वेस्ट को फिर भी जवाब मिलता है (देखें वे रिक्वेस्ट, जिन्हें कोई रूट नहीं लेता); बाकी को कुछ नहीं मिलता।
विफल	वे आदान-प्रदान जिनमें जवाब बनाया या भेजा नहीं जा सका।
बंद रहते	जो एमुलेटर के बंद रहते आया। तब दिखता है, जब उस पर आउटेज सेट हो या कुछ उसे बंद हालत में मिला हो। इसे कभी कोई नियम नहीं में नहीं गिना जाता।
नहीं पहुँचाए गए	केवल MQTT, जब ऐसा हो: वे संदेश जिन्हें लेने में कोई क्लाइंट बहुत पीछे रह गया।

हर नियम का हेडर दिखाता है कि शुरू से अब तक वह कितनी बार मेल खाया।

प्राप्त नवीनतम 300 आदान-प्रदान दिखाता है, सबसे नया सबसे ऊपर:

कॉलम	क्या
समय	यह कब आया।
स्रोत	क्लाइंट का पता।
रिक्वेस्ट	क्या आया, प्रोटोकॉल नोटेशन में: `GET /users/7`, `/ping 1`, `POWER?`।
नियम	वह नियम जिसने इसे लिया (`#2`), या `—`।
जवाब	क्या वापस गया: `200 OK · 37 B`, `/pong 3`, कोई पेलोड; फ़ॉल्ट के लिए रोका गया या बंद किया गया; जवाब विफल होने पर त्रुटि; बंद रहते आने पर बंद था।
ms	आने से लेकर जवाब निकलने तक, उसका विलंब मिलाकर।

किसी पंक्ति का ⌕ बटन (इंस्पेक्टर में खोलें) उस आदान-प्रदान को इंस्पेक्टर में खोलता है, अगर कैप्चर चालू था। जब सेकंड के पाँचवें हिस्से में 200 से ज़्यादा आदान-प्रदान आते हैं, तो सूची कुछ को छोड़ देती है और बताती है कि कितने। इंजन हर चल रहे एमुलेटर के नवीनतम 500 आदान-प्रदान, जो आया उसके साथ, कमांड लाइन, API और MCP के लिए रखता है।

HTTP API

एक HTTP/1.1 सर्वर। हर रिक्वेस्ट का जवाब वह पहला रूट देता है जो उसे लेता है।

रूट

रूट किसी रिक्वेस्ट को तब लेता है, जब उसका मेथड, उसका पाथ और उसकी सभी शर्तें मेल खाती हैं।

फ़ील्ड	क्या
मेथड	`GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD`, `OPTIONS`, या कोई भी। `GET` रूट `HEAD` का भी जवाब देता है।
पाथ	`/` से शुरू होता है। `:name` सेगमेंट कोई भी एक सेगमेंट लेता है, जिसे `{{request.params.name}}` के रूप में पढ़ा जाता है; अंतिम सेगमेंट `*` उसके नीचे का सब कुछ लेता है। अंत का `/` कोई फ़र्क नहीं डालता; क्वेरी स्ट्रिंग पाथ का हिस्सा नहीं है।
शर्तें	हर एक पूरी होनी चाहिए। ＋ शर्त से एक जोड़ें।

पाथ के उदाहरण:

पाथ	लेता है	नहीं लेता
`/health`	`/health`, `/health/`	`/health/db`, `/Health`
`/users/:id`	`/users/7` (`params.id` है `7`), `/users/a%20b` (`a b`)	`/users`, `/users/7/orders`
`/files/*`	`/files`, `/files/a`, `/files/a/b/c`	`/file`, `/other/files/a`

शर्त रिक्वेस्ट का एक हिस्सा पढ़ती है (कहाँ) और उसकी तुलना करती है:

कहाँ	नाम	क्या पढ़ती है
हेडर	हेडर का नाम, किसी भी केस में	हेडर का मान; कई बार भेजे गए हेडर के मान `,` से जोड़कर।
क्वेरी	क्वेरी पैरामीटर	उसका मान, डिकोड करके; दोहराए जाने पर पहला।
बॉडी	—	पूरी बॉडी, टेक्स्ट के रूप में।
JSON	JSON पाथ, जैसे `$.user.id`	JSON बॉडी का वह फ़ील्ड।

तुलना के विकल्प हैं: के बराबर है, के बराबर नहीं है, से कम है, से अधिक नहीं है, से अधिक है, से कम नहीं है, को शामिल करता है, regex से मेल खाता है, खाली है और खाली नहीं है। संख्याओं की तुलना संख्या के रूप में होती है, टेक्स्ट की ठीक-ठीक। जो हेडर, पैरामीटर या फ़ील्ड मौजूद नहीं है, वह ख़ाली माना जाता है। जो तुलना की ही नहीं जा सकती — टेक्स्ट की संख्या से — वह पूरी नहीं होती।

रिस्पॉन्स

रूट में एक से 16 तक रिस्पॉन्स (रिस्पॉन्स) होते हैं।

फ़ील्ड	क्या	डिफ़ॉल्ट
स्टेटस	100–599।	200
फ़ॉल्ट	जवाब के बजाय कुछ और; देखें फ़ॉल्ट।	कोई नहीं — जवाब दें
विलंब, ms	जवाब देने से पहले कितनी देर प्रतीक्षा करनी है, 0–60,000 ms।	0
जिटर, ms	रैंडम रूप से इतना तक और देर, 0–60,000 ms।	0
वज़न	जब रूट रैंडम रूप से जवाब देता है, तब इसका हिस्सा। केवल तभी दिखता है।	1
हेडर	अधिकतम 32। नामों में पैरामीटर हो सकते हैं; मान टेम्पलेट होते हैं।	कोई नहीं
बॉडी	एक टेम्पलेट, लिखे गए रूप में अधिकतम 256 KiB।	ख़ाली

Content-Type हेडर के बिना, जो बॉडी वैध JSON है वह application/json के रूप में जाती है और बाकी हर बॉडी text/plain; charset=utf-8 के रूप में।

दो या अधिक रिस्पॉन्स होने पर कौन-सा रिस्पॉन्स तय करता है कि रिक्वेस्ट को कौन-सा मिले:

कौन-सा रिस्पॉन्स	रिक्वेस्ट को मिलता है	किसके लिए
क्रम से, फिर अंतिम	पहला, दूसरा, …, फिर उसके बाद हमेशा अंतिम: 500, 500, 200, 200, 200…	दोबारा प्रयास: दो बार विफल, फिर सफल।
बारी-बारी से	अंतिम के बाद फिर से पहला: 200, 500, 200, 500…	ऐसी डिपेंडेंसी जो नियमित रूप से बीच-बीच में विफल होती है।
रैंडम, वज़न के अनुसार	हर एक उसके वज़न के अनुसार चुना जाता है। वज़न 8 और 2 होने पर पहला लगभग 80 % बार मिलता है। कम से कम एक वज़न 0 से अधिक होना चाहिए।	विफलताओं का यथार्थवादी हिस्सा।

रिस्पॉन्स जोड़ें रूट में एक तैयार रिस्पॉन्स जोड़ता है:

प्रीसेट	क्या जोड़ता है
200 JSON	200, `{"ok":true}`
201 Created	201, `{"id":"{{uuid}}"}`, हेडर `Location: {{request.path}}/{{counter}}`
404 Not found	404, `{"error":"not found"}`
500 Server error	500, `{"error":"internal"}`
503 Unavailable	503, `{"error":"unavailable"}`, हेडर `Retry-After: 1`
धीमा — 2 s	200, `{"ok":true}`, 2000 ms बाद
कोई जवाब नहीं	फ़ॉल्ट कोई जवाब नहीं
कनेक्शन बंद	फ़ॉल्ट कनेक्शन बंद करें
विकृत JSON	200, `{"items":[{"id":1},{"id":2}]}`, फ़ॉल्ट विकृत बॉडी के साथ

फ़ॉल्ट

फ़ॉल्ट	क्लाइंट को क्या मिलता है
कोई नहीं — जवाब दें	रिस्पॉन्स।
कोई जवाब नहीं	कुछ नहीं। रिक्वेस्ट को अधिकतम 2 मिनट तक रोके रखा जाता है, फिर कनेक्शन बंद कर दिया जाता है — इसलिए टेस्ट क्लाइंट के अपने टाइमआउट का होता है। विलंब लागू नहीं होता।
कनेक्शन बंद करें	विलंब के बाद, बिना जवाब के कनेक्शन बंद हो जाता है।
विकृत बॉडी	सेट किए गए स्टेटस और हेडर वाला एक पूरा HTTP जवाब, जिसकी बॉडी बीच में रुक जाती है: ऐसा JSON जो पार्स नहीं होता। जब पूरी बॉडी JSON थी, तो कंटेंट टाइप फिर भी `application/json` बताता है।

वे रिक्वेस्ट, जिन्हें कोई रूट नहीं लेता

वे रिक्वेस्ट, जिन्हें कोई रूट नहीं लेता तय करता है कि किसी रूट से मेल न खाने वाली रिक्वेस्ट को क्या मिले:

404 Not found — बॉडी {"error":"no_route"} के साथ 404;
यह जवाब — आपका सेट किया गया रिस्पॉन्स, उन सभी चीज़ों के साथ जो किसी रूट के रिस्पॉन्स में होती हैं। इसका {{counter}} उन रिक्वेस्ट को गिनता है जिन्हें किसी रूट ने नहीं लिया।

दोनों ही स्थितियों में रिक्वेस्ट कोई नियम नहीं में गिनी जाती है।

HTTP जवाब क्या पढ़ सकता है

टेम्पलेट	क्या है
`{{request.method}}`	`GET`, `POST`, …
`{{request.path}}`	पाथ, क्वेरी के बिना।
`{{request.params.id}}`	`:id` नाम वाला पाथ सेगमेंट।
`{{request.query.page}}`	क्वेरी पैरामीटर, डिकोड किया हुआ।
`{{request.headers.x-key}}`	कोई हेडर; नाम छोटे अक्षरों में।
`{{request.body}}`	बॉडी, टेक्स्ट के रूप में: उसके पहले 64 KiB।
`{{request.json.name}}`	JSON बॉडी का कोई फ़ील्ड, जब बॉडी JSON हो और 64 KiB के भीतर हो।
`{{request.from}}`	क्लाइंट का `IP:port`।

1 MiB से बड़ी रिक्वेस्ट बॉडी को 413 मिलता है और उसे विफल में गिना जाता है। जो जवाब बनाया ही नहीं जा सकता — ऐसा टेम्पलेट जो किसी ऐसी चीज़ का नाम लेता है जो रिक्वेस्ट में नहीं है — उसे बॉडी में त्रुटि के साथ 500 मिलता है, और उसे विफल में गिना जाता है।

OSC डिवाइस

आने वाले हर संदेश का — बंडल के हर संदेश का अलग से — जवाब वह पहला नियम देता है जिससे वह मेल खाता है। जो डेटाग्राम OSC नहीं है, उसे कोई नियम नहीं में गिना जाता है।

फ़ील्ड	क्या
पता पैटर्न	OSC 1.0 पता पैटर्न: `*` कोई भी अक्षर, `?` एक अक्षर, `[a-z]` एक समूह, `{a,b}` दोनों में से कोई, हर एक एक ही सेगमेंट के भीतर (देखें OSC)।
आर्ग्युमेंट नियम	आर्ग्युमेंट पर अधिकतम 16 शर्तें, जैसे OSC की प्रतीक्षा में (देखें नोड)।
जवाब दें	बंद: संदेश लें और कोई जवाब न दें।
जवाब का पता	जवाब का पता, एक टेम्पलेट।
जवाब के आर्ग्युमेंट	अधिकतम 16 आर्ग्युमेंट, हर एक का प्रकार (`int`, `float`, `str`, `long`, `double`, `bool`, `blob`, `nil`) और मान टेम्पलेट।
जवाब किसे	ख़ाली: भेजने वाले के पते और पोर्ट पर वापस। अन्यथा `IP:port`।
विलंब, ms, जिटर, ms	हर एक 0–60,000 ms।

टेम्पलेट भरने के बाद आर्ग्युमेंट का मान उसके प्रकार के रूप में पढ़ा जाता है: प्रकार संख्या होने पर {{request.args[0]}} पहले आर्ग्युमेंट को संख्या के रूप में लौटाता है। bool में true, 1, yes, on या false, 0, no, off चलते हैं; blob में hex बाइट; ख़ाली मान उस प्रकार का शून्य होता है।

जवाब एमुलेटर के अपने पोर्ट से निकलते हैं, इसलिए जो क्लाइंट उसी पोर्ट पर सुनता है जिससे उसने भेजा था, उसे वे सुनाई देते हैं।

OSC जवाब {{request.address}}, {{request.args[0]}} और {{request.from}} पढ़ सकता है।

UDP डिवाइस

हर डेटाग्राम का जवाब वह पहला नियम देता है जिससे वह मेल खाता है।

फ़ील्ड	क्या
मिलान	कोई भी डेटाग्राम, टेक्स्ट शामिल है, regex से मेल खाता है या बाइट शामिल हैं (hex)।
पैटर्न	खोजा जाने वाला टेक्स्ट, रेगुलर एक्सप्रेशन या बाइट।
जवाब	बिना जवाब के लें, टेक्स्ट या Hex, फिर ख़ुद जवाब, एक टेम्पलेट के रूप में।
जवाब किसे	ख़ाली: भेजने वाले को वापस। अन्यथा `IP:port`।
विलंब, ms, जिटर, ms	हर एक 0–60,000 ms।

UDP या TCP जवाब पढ़ सकता है:

टेम्पलेट	क्या है
`{{request.text}}`	पेलोड, टेक्स्ट के रूप में।
`{{request.match}}`	जो मेल खाया: टेक्स्ट, रेगुलर एक्सप्रेशन का पहला ग्रुप (या पूरा मिलान), बाइट।
`{{request.hex}}`	पेलोड, hex बाइट के रूप में, उसके पहले 1024।
`{{request.bytes}}`	पेलोड का आकार।
`{{request.from}}`	भेजने वाले का `IP:port`।

टेक्स्ट जवाब अधिकतम 65,507 बाइट का होता है।

TCP डिवाइस

ऐसा डिवाइस जो TCP कनेक्शन पर पंक्तियों में बात करता है, जैसे प्रोजेक्टर या मैट्रिक्स स्विचर। क्लाइंट का भेजा हर संदेश उस पहले नियम से जवाब पाता है जिससे वह मेल खाता है; जवाब उसी कनेक्शन पर वापस जाता है।

फ़ील्ड	क्या
संदेश का अंत	संदेश किससे समाप्त होता है, और जो हर जवाब और अभिवादन के बाद जोड़ा जाता है: LF (\n) (उससे पहले का `\r` हटा दिया जाता है), CR LF (\r\n), CR (\r), या कोई नहीं — हर चंक। ख़ाली पंक्तियाँ छोड़ दी जाती हैं।
अभिवादन	क्लाइंट के कनेक्ट होते ही भेजा जाता है; ख़ाली हो तो कुछ नहीं। यह `{{request.from}}` पढ़ सकता है।
मिलान, पैटर्न, जवाब	जैसे UDP डिवाइस में।
फिर कनेक्शन बंद करें	इस नियम के जवाब के बाद कनेक्शन बंद करें — जैसे `QUIT` पर।
विलंब, ms, जिटर, ms	हर एक 0–60,000 ms।

अपने डिलिमिटर के बिना 64 KiB से लंबा संदेश जैसा है वैसा ही लिया जाता है।

MQTT ब्रोकर

सादे TCP पर एक छोटा MQTT 3.1.1 ब्रोकर। यह वही करता है जो कोई ब्रोकर करता है: क्लाइंट कनेक्ट होते हैं, + और # के साथ सब्सक्राइब करते हैं, QoS 0, 1 और 2 पर पब्लिश करते हैं, retained संदेश और लास्ट-विल काम करते हैं, और किसी क्लाइंट की id वाला दूसरा कनेक्शन पहले की जगह ले लेता है। सेशन हमेशा क्लीन होते हैं: अपना सेशन बनाए रखने को कहने वाले क्लाइंट को नया सेशन मिलता है, और अनुपस्थित क्लाइंट के लिए कुछ भी कतार में नहीं रखा जाता।

इसके ऊपर, इस पर पब्लिश किया गया हर संदेश नियमों से जाँचा जाता है: जो पहला मेल खाता है, वह एक जवाब भी पब्लिश करता है — जैसे कोई डिवाइस बता रहा हो कि उसने क्या किया।

फ़ील्ड	क्या
उपयोगकर्ता नाम, पासवर्ड	उपयोगकर्ता नाम सेट होने पर क्लाइंट को उसी और पासवर्ड के साथ कनेक्ट करना होगा; ख़ाली: कोई भी कनेक्ट कर सकता है। उपयोगकर्ता नाम के बिना पासवर्ड अस्वीकार किया जाता है, क्योंकि MQTT 3.1.1 उसे नहीं ले जा सकता।
retained संदेश	अधिकतम 64 संदेश (टॉपिक, पेलोड, QoS), जो शुरू से रखे जाते हैं, मानो retain के साथ पब्लिश किए गए हों: सब्सक्राइब करने वाले क्लाइंट को सबसे पहले ये मिलते हैं।
टॉपिक फ़िल्टर	नियम कौन-से टॉपिक लेता है: `+` एक लेवल, `#` बाकी सब — `lab/+/set`।
मिलान, पैटर्न	पेलोड पर एक शर्त, जैसे UDP डिवाइस में।
जवाब दें	बंद: संदेश लें और आगे कुछ पब्लिश न करें।
जवाब का टॉपिक, जवाब का पेलोड	टेम्पलेट। टॉपिक में `+` या `#` नहीं हो सकता।
QoS, retain	जवाब के।
विलंब, ms, जिटर, ms	हर एक 0–60,000 ms।

MQTT जवाब {{request.topic}}, {{request.levels[1]}} (टॉपिक के लेवल, 0 से), {{request.payload}}, {{request.json.state}}, {{request.match}}, {{request.qos}}, {{request.retain}}, {{request.client}} (क्लाइंट id) और {{request.from}} पढ़ सकता है।

जवाबों में टेम्पलेट

जवाब उसी टेम्पलेट भाषा में लिखे जाते हैं जिसमें प्रयोग, इसलिए किसी फ़ील्ड का यहाँ और वहाँ एक ही अर्थ होता है। जवाब पढ़ सकता है:

request — जो आया, जैसा ऊपर हर प्रोटोकॉल के लिए बताया गया है;
{{counter}} — एमुलेटर के शुरू होने के बाद से इस नियम ने कितने संदेश लिए, यह वाला मिलाकर;
जनरेटर — {{uuid}}, {{now.iso}}, रैंडम मान और बाकी; रैंडम मान एमुलेटर के सीड से निकाले जाते हैं;
पैरामीटर, जब एमुलेटर किसी प्रयोग में चलता है या signallab emulate --param के साथ शुरू किया जाता है।

जवाब कभी सीक्रेट नहीं पढ़ता, और अज्ञात नाम एक त्रुटि है, ख़ाली टेक्स्ट नहीं।

कुछ फ़ील्ड एमुलेटर के शुरू होने पर, कुछ भी आने से पहले, तय हो जाते हैं: पाथ, शर्त, पता पैटर्न, पेलोड पैटर्न, टॉपिक फ़िल्टर, जवाब किसे, हेडर का नाम, retained संदेश और ब्रोकर का लॉगिन। इनमें केवल टेक्स्ट और पैरामीटर चलते हैं, न request और न जनरेटर।

सीड रिस्पॉन्स के रैंडम क्रम, जिटर और रैंडम जनरेटर को तय करता है। एमुलेटर स्क्रीन पर हर बार शुरू करने पर नया सीड लिया जाता है; प्रयोग रन के सीड का उपयोग करता है, और signallab emulate --seed आपका दिया हुआ सीड लेता है।

बंद होना

डिपेंडेंसी के बार-बार गिरने-उठने पर आपका सिस्टम क्या करता है, यह टेस्ट करने के लिए बीच-बीच में बंद होता है पर टिक करें:

फ़ील्ड	क्या	डिफ़ॉल्ट
चालू अवधि, ms	यह कितनी देर जवाब देता है, 10–36,00,000 ms।	10,000
बंद अवधि, ms	यह कितनी देर बंद रहता है, 10–36,00,000 ms।	3000
बंद रहते समय	केवल HTTP: बंद रहते समय रिक्वेस्ट को क्या मिलता है।	503 Unavailable

शेड्यूल एमुलेटर के शुरू होने पर शुरू होता है और दोहराता है: चालू, बंद, चालू, बंद… बंद रहते समय:

एमुलेटर	क्या मिलता है
HTTP	503 Unavailable: 503, जिसमें `Retry-After` लौटने तक बचे सेकंड पर सेट होता है (कम से कम 1)। कनेक्शन बंद करें: कनेक्शन बिना जवाब के बंद हो जाता है। कोई जवाब नहीं: अधिकतम 2 मिनट तक रोका जाता है, फिर बंद।
TCP डिवाइस	खुले कनेक्शन 0.1 s के भीतर तोड़ दिए जाते हैं; नए कनेक्शन आते ही बंद कर दिए जाते हैं।
MQTT ब्रोकर	हर कनेक्शन तोड़ दिया जाता है; नए अस्वीकार किए जाते हैं (CONNACK रिटर्न कोड 3, server unavailable)।
OSC, UDP डिवाइस	किसी को जवाब नहीं दिया जाता।

बंद रहते जो आता है, वह बंद रहते में गिना जाता है, कोई नियम नहीं में नहीं, और उसके लिए नियमों से नहीं पूछा जाता।

बंद करें यही काम माँग पर करता है, शेड्यूल चाहे जो कहे, तब तक जब तक आप चालू करें न दबाएँ; तब HTTP को Retry-After के बिना 503 मिलता है। प्रयोग में एमुलेटर बंद/चालू नोड यह रन के किसी चरण पर करता है (देखें नोड और फ़ॉल्ट)।

समस्याएँ

संपादन के दौरान हर बदलाव के कुछ क्षण बाद एमुलेटर जाँचा जाता है, और आपके शुरू करें दबाने से पहले ही समस्या उसके बटनों के नीचे दिख जाती है। समस्या बताती है कि वह कहाँ है — नियम, रिस्पॉन्स या retained संदेश, और फ़ील्ड — और क्या ग़लत है: / के बिना पाथ, ऐसा रेगुलर एक्सप्रेशन जो कंपाइल नहीं होता, ऐसा जवाब टेम्पलेट जो request, पैरामीटर और जनरेटर के अलावा किसी और चीज़ का नाम लेता है, सीमा से बाहर का मान। शुरू करें समस्या वाले एमुलेटर को अस्वीकार कर देता है।

सीमाएँ

क्या	सीमा	सीमा पर
प्रति एमुलेटर रूट या नियम	64	जाँच में अस्वीकार।
प्रति रूट रिस्पॉन्स	16	अस्वीकार।
प्रति रूट शर्तें	16	अस्वीकार।
प्रति रिस्पॉन्स हेडर	32	अस्वीकार।
आर्ग्युमेंट शर्तें, जवाब के आर्ग्युमेंट (OSC)	हर एक 16	अस्वीकार।
retained संदेश (MQTT)	64	अस्वीकार।
लिखे गए रूप में बॉडी, जवाब या अभिवादन	256 KiB	अस्वीकार।
विलंब या जिटर	60,000 ms	अस्वीकार।
HTTP रिक्वेस्ट बॉडी	1 MiB	413।
एक साथ HTTP कनेक्शन	512	और कनेक्शन आते ही बंद कर दिए जाते हैं।
HTTP रिक्वेस्ट हेड	30 s	क्लाइंट को इसी समय में इसे भेजना होगा।
एक साथ TCP कनेक्शन	256	और कनेक्शन आते ही बंद कर दिए जाते हैं।
अपने विलंब की प्रतीक्षा में OSC और UDP जवाब	1024	और जवाब ड्रॉप होते हैं और विफल में गिने जाते हैं।
एक साथ MQTT क्लाइंट	256	और क्लाइंट आते ही बंद कर दिए जाते हैं।
MQTT पैकेट	256 KiB	क्लाइंट का कनेक्शन समाप्त हो जाता है।
प्रति क्लाइंट MQTT सब्सक्रिप्शन	100	और अस्वीकार किए जाते हैं।
MQTT retained टॉपिक	1000 टॉपिक, 16 MiB	नया retained संदेश रूट किया जाता है, retain नहीं किया जाता।
एक धीमे क्लाइंट की प्रतीक्षा में MQTT संदेश	1024 संदेश, 8 MiB	वह इन्हें खो देता है; नहीं पहुँचाए गए में गिना जाता है।

इसका मॉक बनाना

किसी सफल रिस्पॉन्स से एमुलेटर बनाने के लिए:

HTTP स्क्रीन पर रिक्वेस्ट भेजें और रिस्पॉन्स पाएँ — या किसी प्रयोग के HTTP नोड पर अभी भेजें का उपयोग करें।
रिस्पॉन्स के पास ⧉ इसका मॉक बनाएँ दबाएँ। इस रिस्पॉन्स का मॉक बनाएँ डायलॉग दिखाता है कि वह कौन-सा रूट बनाएगा।
इसमें जोड़ें में अपने HTTP एमुलेटर में से एक चुनें, या नया एमुलेटर।
रूट जोड़ें दबाएँ। एमुलेटर स्क्रीन उसी एमुलेटर पर खुलती है।

रूट रिक्वेस्ट के मेथड और पाथ (क्वेरी के बिना) का जवाब रिस्पॉन्स के स्टेटस, हेडर और बॉडी से देता है। जो हेडर केवल उस एक आदान-प्रदान के होते हैं (Content-Length, Date, Server, ETag और इसी तरह के), वे छोड़ दिए जाते हैं, और बॉडी वैसी ही भेजी जाती है जैसी थी, भले ही उसमें {{ हो। नए एमुलेटर में केवल यही रूट होता है। किसी मौजूदा एमुलेटर में जोड़ने पर रूट सबसे पहले आता है, ताकि वह किसी व्यापक रूट से पहले जवाब दे; चल रहा एमुलेटर इसे तब अपनाता है जब आप रीस्टार्ट करें दबाते हैं।

प्रयोग से, टेम्पलेट के साथ लिखा URL एक पैटर्न बन जाता है: उसका आधार ({{api}}) हटा दिया जाता है, जो सेगमेंट एक ही टेम्पलेट है (/orders/{{order_id}}), वह :order_id बन जाता है, और जो सेगमेंट केवल आंशिक रूप से टेम्पलेट है, वह पाथ को * के साथ समाप्त कर देता है।

शुरुआती सेट

जब Signal Lab को पहली बार कोई एमुलेटर लाइब्रेरी नहीं मिलती, तो वह पाँच एमुलेटर लिखता है, सभी इसी कंप्यूटर पर। उनके नाम और नोट उस समय की इंटरफ़ेस भाषा में लिखे जाते हैं।

एमुलेटर	कहाँ सुनता है	क्या करता है
डेमो API	`127.0.0.1:8080`	`GET /health` → `{"status":"ok","time":…}`; `GET /users/:id` → उस id वाला उपयोगकर्ता; `POST /users` → `Location` के साथ 201; `GET /slow` → 1500 ms बाद; `/flaky` → 503, 503, फिर उसके बाद हमेशा 200।
डेमो OSC डिवाइस	`127.0.0.1:9100`	`/ping` → गिनती के साथ `/pong`; `/fader/` → मिले पते के साथ `/ack`; `/cue/` बिना जवाब के लिया जाता है।
डेमो UDP डिवाइस	`127.0.0.1:7100`	`PING` → `PONG` और गिनती; बाकी कुछ भी → `ACK` और बाइट में उसका आकार।
डेमो TCP डिवाइस	`127.0.0.1:7200`	CR LF से समाप्त होने वाली पंक्तियाँ। `READY` से अभिवादन करता है; `POWER?` → `POWER=ON`; `POWER ON` या `POWER OFF` → `OK ON` / `OK OFF`; `QUIT` → `BYE`, फिर कनेक्शन काट देता है।
डेमो MQTT ब्रोकर	`127.0.0.1:1883`	`lab/status` पर `online` retain करता है; `lab/<name>/set` पर पब्लिश किया गया `ON` या `OFF` → वही, retained, `lab/<name>/state` पर।

सिग्नल लाइब्रेरी का शुरुआती सिग्नल क्या सेवा चालू है?http://127.0.0.1:8080/ से पूछता है, जो डेमो API का पता है: उसमें / के लिए कोई रूट नहीं है, इसलिए उसे 404 मिलता है।

लाइब्रेरी फ़ाइल

लाइब्रेरी डेटा फ़ोल्डर में emulators.json है (देखें फ़ाइलें); उसका पथ देखने के लिए सूची के नीचे की गिनती पर पॉइंटर रखें। अंतिम बदलाव के 0.7 s बाद यह पूरी की पूरी, एक अस्थायी फ़ाइल के ज़रिए, लिखी जाती है, इसलिए विफल लेखन पिछली फ़ाइल को बनाए रखता है। अगर फ़ाइल पढ़ी नहीं जा सकती, तो सूची पथ, पंक्ति और कॉलम के साथ त्रुटि दिखाती है, और फ़ाइल को जैसी है वैसी ही छोड़ दिया जाता है: उसे ठीक करें और फ़ाइल फिर से लोड करें दबाएँ। हाथ से संपादित करने के बाद भी फ़ाइल फिर से लोड करें दबाएँ। फ़ाइल न होने पर शुरुआती सेट फिर से लिखा जाता है।

json

{
  "version": 1,
  "emulators": [
    {
      "id": "orders-api",
      "note": "Stands in for the orders service.",
      "emulator": {
        "name": "Orders API",
        "bind": "127.0.0.1:18080",
        "protocol": "http",
        "routes": [
          { "method": "GET", "path": "/orders/:id",
            "responses": [{ "body": "{\"id\":\"{{request.params.id}}\",\"state\":\"open\"}" }] },
          { "method": "POST", "path": "/orders", "order": "sequence",
            "responses": [{ "status": 503 }, { "status": 201, "body": "{\"id\":\"{{uuid}}\"}" }] }
        ],
        "outage": { "up_ms": 20000, "down_ms": 2000, "fault": "unavailable" }
      }
    }
  ]
}

अकेला emulator ऑब्जेक्ट भी एक दस्तावेज़ है, जिसे signallab emulate पढ़ता है।

प्रयोगों और स्क्रिप्ट में

प्रयोग में एमुलेटर नोड अपना एमुलेटर पहले चरण से पहले खोलता है और रन समाप्त होने तक जवाब देता है; उसे जो प्राप्त हुआ, वह रिपोर्ट में गिना जाता है। वहाँ HTTP एमुलेटर वही है जिसे HTTP रिक्वेस्ट की प्रतीक्षा (नोड) सुनता है, और OSC या UDP एमुलेटर अपना पोर्ट रन की प्रतीक्षाओं के साथ साझा करता है। एक प्रयोग में एक ही ट्रांसपोर्ट के दो एमुलेटर एक पोर्ट साझा नहीं कर सकते। देखें नोड और फ़ॉल्ट।
signallab emulate फ़ाइलों से या इस लाइब्रेरी से एमुलेटर Ctrl+C या --for तक चलाता है और बताता है कि वे क्या जवाब देते हैं; देखें कमांड लाइन।

इंस्पेक्टर — हर आदान-प्रदान, डिकोड किया हुआ।
बाधा — आपके सिस्टम और एमुलेटर के बीच ख़राब नेटवर्क।
डेटा और टेम्पलेट

एमुलेटर ​

स्क्रीन ​

एमुलेटर बनाना ​

इसे चलाना ​

क्या आया ​

HTTP API ​

रूट ​

रिस्पॉन्स ​

फ़ॉल्ट ​

वे रिक्वेस्ट, जिन्हें कोई रूट नहीं लेता ​

HTTP जवाब क्या पढ़ सकता है ​

OSC डिवाइस ​

UDP डिवाइस ​

TCP डिवाइस ​

MQTT ब्रोकर ​

जवाबों में टेम्पलेट ​

बंद होना ​

समस्याएँ ​

सीमाएँ ​

इसका मॉक बनाना ​

शुरुआती सेट ​

लाइब्रेरी फ़ाइल ​

प्रयोगों और स्क्रिप्ट में ​

संबंधित ​