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"
}
فیلدهای ضروری
| فیلد | نوع | توضیح |
|---|---|---|
name | string | نام دلخواه node. |
type | string | باید TesterClient باشد. |
next | string | nodeای که line یا packet line تست را دریافت میکند. |
settings اختیاری است؛ اگر آن را ننویسید، node با تنظیمات پیشفرض stream mode کار میکند.
تنظیمات
| فیلد | پیشفرض | توضیح |
|---|---|---|
packet-mode | false | بهجای lineهای معمولی stream از packet line هر worker استفاده میکند. |
packet-start-immediately | false | فقط در packet mode؛ ارسال را بدون انتظار برای downstream Est آغاز میکند. |
packet-start-delay-ms | 0 | فقط در packet mode؛ تأخیر مسیر immediate-start. نباید منفی باشد. |
allow-early-response | false | فقط در stream mode؛ اجازه میدهد پیش از ارسال کامل request sequence، پاسخ downstream دریافت شود. |
packet-stateless | false | فقط در packet mode؛ response packetها میتوانند خارج از ترتیب برسند و بر اساس اندازه شناسایی میشوند. |
chunk-count | 11 | تعداد chunkهای فعال از ابتدای جدول. بازه معتبر 1 تا 11. |
max-payload-size | 0 | حداکثر اندازه bufferهای stream یا packetها. مقدار 0 یعنی استفاده از اندازه معمول جدول یا buffer. |
split-payload-delay-ms | 1 | فقط در stream mode؛ فاصله ارسال payloadهای تکهشده، زمانی که max-payload-size فعال است. |
split-payload-burst | 1 | فقط در 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. |
protocol | tcp یا udp. |
حالت packet IPv4
packet-ipv4 فقط با packet-mode=true معتبر است و هر payload را به یک packet کامل و مصنوعی IPv4 تبدیل میکند.
فیلدهای ضروری:
| فیلد | توضیح |
|---|---|
source-ip | آدرس IPv4 مبدأ برای request packetها. |
dest-ip | آدرس IPv4 مقصد برای request packetها. |
فیلدهای اختیاری:
| فیلد | پیشفرض | توضیح |
|---|---|---|
transport | none | header اختیاری transport؛ یکی از tcp، udp، icmp، raw یا none. |
protocol | 253 | شماره protocol در IPv4. برای tcp، udp یا icmp باید با transport انتخابشده هماهنگ باشد. |
ttl | 64 | مقدار TTL در IPv4. |
worker-affine-flow | false | برای هر 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:
- در packet mode از packet line همان worker استفاده میکند و در غیر این صورت یک line معمولی stream میسازد
- line state این tunnel را مقداردهی اولیه میکند
- در صورت وجود،
dest-contextرا روی line کپی میکند - upstream
Initرا به node بعدی میفرستد - یک 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 flags | kNodeFlagChainHead | kNodeFlagSingleton |
can_have_prev | false |
can_have_next | true |
layer_group | kNodeLayerAnything |
layer_group_prev_node | kNodeLayerNone |
layer_group_next_node | kNodeLayerAnything |
required_padding_left | 0 بایت |