پرش به مطلب اصلی

TesterClient

TesterClient یک node آزمایشی در ابتدای chain است. ترافیک deterministic و قابل تکرار تولید می‌کند، آن را به node بعدی می‌فرستد و ترتیب پاسخ‌های برگشتی را با الگوی مورد انتظار می‌سنجد. اگر پاسخ‌ها تطابق نداشته باشند یا timeout رخ دهد، اجرای process متوقف می‌شود.

از این node برای آزمایش ترکیب tunnel‌ها، framing، مدیریت packet، ترتیب داده‌ها و سالم ماندن payload استفاده کنید. TesterClient برای ترافیک واقعی و محیط production ساخته نشده است.

جایگاه رایج​

stream mode:

TesterClient -> SomeTunnel -> SomeTunnel -> TesterServer

packet mode:

TesterClient(packet-mode=true) -> PingClient -> PingServer -> TesterServer(packet-mode=true)

در این chain مستقیم Ping، ‏handshake عادی Init/Est مربوط به packet line جریان request را شروع می‌کند و نیازی به packet-start-immediately نیست.

تست stream حساس به datagram:

TesterClient -> TcpOverUdpClient -> TcpOverUdpServer -> TesterServer

TesterClient باید در ابتدای chain قرار بگیرد. این node singleton است، بنابراین هر config باید فقط یک instance از آن داشته باشد.

نمونه تنظیم​

stream mode:

{
"name": "tester-client",
"type": "TesterClient",
"next": "next-node"
}

packet mode:

{
"name": "tester-client",
"type": "TesterClient",
"settings": {
"packet-mode": true
},
"next": "packet-node"
}

packet mode همراه با IPv4 مصنوعی:

{
"name": "tester-client",
"type": "TesterClient",
"settings": {
"packet-mode": true,
"packet-ipv4": {
"source-ip": "198.51.100.10",
"dest-ip": "203.0.113.20",
"transport": "udp",
"ttl": 64
}
},
"next": "packet-node"
}

فیلدهای ضروری​

فیلدنوعتوضیح
namestringنام دلخواه node.
typestringباید TesterClient باشد.
nextstringnode‌ای که line یا packet line تست را دریافت می‌کند.

settings اختیاری است؛ اگر آن را ننویسید، node با تنظیمات پیش‌فرض stream mode کار می‌کند.

تنظیمات​

فیلدپیش‌فرضتوضیح
packet-modefalseبه‌جای line‌های معمولی stream از packet line هر worker استفاده می‌کند.
packet-start-immediatelyfalseفقط در packet mode؛ ارسال را بدون انتظار برای downstream Est آغاز می‌کند.
packet-start-delay-ms0فقط در packet mode؛ تأخیر مسیر immediate-start. نباید منفی باشد.
allow-early-responsefalseفقط در stream mode؛ اجازه می‌دهد پیش از ارسال کامل request sequence، پاسخ downstream دریافت شود.
packet-statelessfalseفقط در packet mode؛ response packet‌ها می‌توانند خارج از ترتیب برسند و بر اساس اندازه شناسایی می‌شوند.
chunk-count11تعداد chunk‌های فعال از ابتدای جدول. بازه معتبر 1 تا 11.
max-payload-size0حداکثر اندازه buffer‌های stream یا packet‌ها. مقدار 0 یعنی استفاده از اندازه معمول جدول یا buffer.
split-payload-delay-ms1فقط در stream mode؛ فاصله ارسال payload‌های تکه‌شده، زمانی که max-payload-size فعال است.
split-payload-burst1فقط در stream mode؛ تعداد buffer‌هایی که پیش از اعمال split-payload-delay-ms فرستاده می‌شوند. باید مثبت باشد.
dest-contextنداردdestination routing context اولیه که پیش از upstream Init روی هر line آزمایشی کپی می‌شود.
packet-ipv4نداردفقط در packet mode؛ هر packet آزمایشی را در یک packet مصنوعی IPv4 قرار می‌دهد.

packet-stateless نیازمند packet-mode=true است. max-payload-size با packet-stateless=true پشتیبانی نمی‌شود.

جدول chunk‌ها​

این node درخواست‌ها را در chunk‌هایی با محتوای قطعی می‌فرستد و انتظار دارد پاسخ نیز از همان الگوی قطعی پیروی کند. chunk-count مشخص می‌کند چند عضو نخست جدول فعال باشند.

stream mode:

1, 2, 4, 32, 512, 1024, 4096, 32768, 32769, 1048576, 2097152

packet mode:

1, 2, 4, 32, 64, 128, 256, 512, 1024, 1499, 1500

packet mode با IPv4 خام:

21, 22, 24, 52, 84, 148, 276, 532, 1044, 1499, 1500

packet mode با IPv4 و transport header مثل tcp، udp یا icmp:

41, 42, 44, 52, 84, 148, 276, 532, 1044, 1499, 1500

الگوی بایت‌ها قطعی است و به index هر chunk، offset، flow id و جهت بستگی دارد. نخستین byte درخواست حاوی flow id است تا حتی اگر یک transport واقعی ادامه کار را به worker دیگری سپرد، بررسی پاسخ به‌هم نخورد.

destination context​

dest-context پیش از upstream Init مقدار اولیه line->routing_context.dest_ctx را روی line آزمایشی قرار می‌دهد. این قابلیت برای تست router‌ها، connector‌ها و adapter‌های packet/UDP که metadata مقصد را از line می‌خوانند کاربرد دارد.

{
"dest-context": {
"address": "example.com",
"port": 443,
"protocol": "tcp"
}
}

فیلدها:

فیلدتوضیح
addressآدرس IP یا domain؛ نام domain باید در محدودیت طول address context جا شود.
portپورت مقصد، 1 تا 65535.
protocoltcp یا udp.

حالت packet IPv4​

packet-ipv4 فقط با packet-mode=true معتبر است و هر payload را به یک packet کامل و مصنوعی IPv4 تبدیل می‌کند.

فیلدهای ضروری:

فیلدتوضیح
source-ipآدرس IPv4 مبدأ برای request packet‌ها.
dest-ipآدرس IPv4 مقصد برای request packet‌ها.

فیلدهای اختیاری:

فیلدپیش‌فرضتوضیح
transportnoneheader اختیاری transport؛ یکی از tcp، udp، icmp، raw یا none.
protocol253شماره protocol در IPv4. برای tcp، udp یا icmp باید با transport انتخاب‌شده هماهنگ باشد.
ttl64مقدار TTL در IPv4.
worker-affine-flowfalseبرای هر worker یک request source port انتخاب می‌کند که hash جریان آن به همان worker برسد. packet ورودی نیز پیش از بررسی به worker جریان فرستاده می‌شود تا state بررسی مستقل از worker حامل باشد. فقط با transport از نوع tcp یا udp معتبر است.

در response packet‌ها آدرس مبدأ و مقصد به‌طور خودکار جابه‌جا می‌شوند. برای tcp، udp و icmp، header‌های transport با الگوی قطعی ساخته و بررسی می‌شوند. درخواست‌های TCP و UDP از source port برابر 40123 و destination port برابر 40234 استفاده می‌کنند؛ این دو در پاسخ جابه‌جا می‌شوند. با فعال بودن worker-affine-flow، request source port به‌جای آن نخستین port برابر یا بزرگ‌تر از 40123 است که inner flow آن worker فعلی را انتخاب کند؛ بنابراین هر دو node باید source-ip، ‏dest-ip، ‏transport و خود این setting را یکسان تنظیم کنند.

وقتی packet-ipv4 فعال است، مقدار max-payload-size باید فضای کافی برای header‌های IPv4 و transport انتخاب‌شده باقی بگذارد.

جریان اجرا​

هنگام راه‌اندازی، TesterClient با تأخیر 100 ms برای هر worker یک task زمان‌بندی می‌کند. هر task:

  1. در packet mode از packet line همان worker استفاده می‌کند و در غیر این صورت یک line معمولی stream می‌سازد
  2. line state این tunnel را مقداردهی اولیه می‌کند
  3. در صورت وجود، dest-context را روی line کپی می‌کند
  4. upstream Init را به node بعدی می‌فرستد
  5. یک watchdog به مدت 30000 ms فعال می‌کند

در stream mode، ارسال درخواست‌ها پس از دریافت downstream Est آغاز می‌شود. در packet mode می‌توانید با packet-start-immediately=true این انتظار را حذف کنید.

در شروع فوری packet mode، تأخیر packet-start-delay-ms حتی اگر node بعدی هنگام Init رویداد Est یا Resume بفرستد اعمال می‌شود؛ این رویدادها نه تأخیر را حذف می‌کنند و نه ارسال درخواست را دوباره زمان‌بندی می‌کنند.

downstream Pause و Resume نیز ارسال درخواست‌ها را متوقف یا دوباره برقرار می‌کنند.

بررسی پاسخ​

در stream mode، بایت‌های پاسخ تا کامل شدن هر chunk در buffer می‌مانند و chunk‌ها به‌ترتیب بررسی می‌شوند. هر byte اضافه پس از sequence مورد انتظار یا downstream Finish پیش از پایان بررسی، تست را ناموفق می‌کند.

در packet mode، هر response packet باید دقیقاً با chunk مورد انتظار یکسان باشد. packet line باید در تمام runtime زنده بماند و دریافت Finish روی آن خطاست. با packet-stateless=true پاسخ‌ها می‌توانند خارج از ترتیب برسند، اما هر chunk باید دقیقاً یک بار دریافت شود.

پس از موفقیت همه worker‌ها، TesterClient نتیجه را log می‌کند و برنامه با exit code برابر 0 پایان می‌یابد. mismatch، timeout، رویداد lifecycle نامعتبر یا از بین رفتن packet line باعث شکست تست می‌شود.

خطاهای رایج​

  • استفاده در production؛ این node عمداً برای validation ساخته شده و ممکن است process را متوقف کند.
  • فراموش کردن next؛ TesterClient در ابتدای chain قرار دارد و باید داده را به node دیگری بفرستد.
  • فعال کردن packet mode بدون packet-layer node در chain.
  • انتظار بسته شدن packet line در packet mode؛ packet line‌ها ابزارهای ماندگار هر worker هستند.
  • ترکیب packet-stateless=true با max-payload-size.
  • استفاده از packet-ipv4 بدون packet-mode=true.

متادیتای node​

TesterClient حداکثر از 254 worker پشتیبانی می‌کند و برای هر worker یک watchdog با مدت 30000 ms دارد.

متادیتای برگرفته از کد منبع:

ویژگیمقدار
node flagskNodeFlagChainHead | kNodeFlagSingleton
can_have_prevfalse
can_have_nexttrue
layer_groupkNodeLayerAnything
layer_group_prev_nodekNodeLayerNone
layer_group_next_nodekNodeLayerAnything
required_padding_left0 بایت