TesterServer

TesterServer همتای آزمایشی TesterClient در انتهای chain است. ترتیب قطعی درخواست‌های دریافتی را بررسی می‌کند و پاسخ‌های قطعی را روی همان WaterWall line یا مسیر packet برمی‌گرداند.

با قرار دادن آن در انتهای chain آزمایشی می‌توانید مطمئن شوید نودهای میانی byteهای payload، ترتیب داده‌ها، شکل packet و قواعد lifecycle را حفظ کرده‌اند.

جایگاه رایج

Stream mode:

TesterClient -> SomeTunnel -> SomeTunnel -> TesterServer

تست مستقیم Ping در packet mode:

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

TesterServer معمولاً در انتهای chain قرار می‌گیرد. در chain مستقیم Ping، پس از handshake عادی Init/Est مربوط به packet line، ‏request را در جهت upstream دریافت و response را در جهت downstream ارسال می‌کند. در packet mode می‌تواند برای topologyهای دیگری که عمداً داده را از سمت next/downstream وارد می‌کنند، next هم داشته باشد.

نمونه تنظیم

Stream mode:

{
  "name": "tester-server",
  "type": "TesterServer"
}

Packet mode:

{
  "name": "tester-server",
  "type": "TesterServer",
  "settings": {
    "packet-mode": true
  }
}

Packet mode همراه با startup init:

{
  "name": "tester-server",
  "type": "TesterServer",
  "settings": {
    "packet-mode": true,
    "packet-init-on-start": true,
    "packet-ipv4": {
      "source-ip": "198.51.100.10",
      "dest-ip": "203.0.113.20",
      "transport": "udp",
      "ttl": 64
    }
  }
}

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

فیلد	نوع	توضیح
`name`	string	نام دلخواه نود.
`type`	string	باید `TesterServer` باشد.

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

next فقط وقتی مجاز است که packet-mode=true باشد.

تنظیمات

فیلد	پیش‌فرض	توضیح
`packet-mode`	`false`	به‌جای رفتار معمول lineهای stream از packet line هر worker استفاده می‌کند.
`packet-init-on-start`	`false`	فقط در packet mode؛ اگر پیش‌تر packet-side `Init` نرسیده باشد، هنگام راه‌اندازی state هر worker را یک بار مقداردهی می‌کند.
`streaming-response`	`false`	فقط در stream mode؛ اجازه می‌دهد هر response chunk پس از بررسی request chunk متناظر فرستاده شود.
`packet-stateless`	`false`	فقط در packet mode؛ request packetها می‌توانند خارج از ترتیب یا فقط به‌صورت یک زیرمجموعه برسند و بر اساس اندازه شناسایی می‌شوند.
`chunk-count`	`11`	تعداد chunkهای فعال از ابتدای جدول. بازه معتبر `1` تا `11`.
`max-payload-size`	`0`	حداکثر اندازه buffer پاسخ stream یا packetها. مقدار `0` یعنی استفاده از اندازه معمول جدول یا buffer.
`split-payload-delay-ms`	`1`	فقط در stream mode؛ فاصله ارسال پاسخ‌های تکه‌شده، زمانی که `max-payload-size` فعال است.
`split-payload-burst`	`1`	فقط در stream mode؛ تعداد bufferهایی که پیش از اعمال `split-payload-delay-ms` فرستاده می‌شوند. باید مثبت باشد.
`packet-ipv4`	ندارد	فقط در packet mode؛ request و response را به شکل packetهای کامل و مصنوعی IPv4 در نظر می‌گیرد.

packet-init-on-start، packet-stateless و packet-ipv4 نیازمند packet-mode=true هستند. max-payload-size با packet-stateless=true پشتیبانی نمی‌شود.

جدول chunkها

TesterServer همان جدول‌های قطعی TesterClient را به کار می‌برد. 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

نخستین byte درخواست حاوی flow id انتخاب‌شده توسط client است. TesterServer با همان id محتوای درخواست را بررسی و الگوی پاسخ متناظر را تولید می‌کند؛ حتی اگر درخواست از worker دیگری رسیده باشد.

حالت Packet IPv4

packet-ipv4 فقط با packet-mode=true معتبر است.

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

فیلد	توضیح
`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 هنگام ساخت response packetها.

در response packetها source-ip و dest-ip به‌طور خودکار جابه‌جا می‌شوند. برای tcp، udp و icmp، headerهای transport با الگوی قطعی ساخته و بررسی می‌شوند. درخواست‌های TCP و UDP از source port برابر 40123 و destination port برابر 40234 استفاده می‌کنند؛ این دو در پاسخ جابه‌جا می‌شوند.

جریان اجرا

با دریافت upstream Init، نود:

line state خود را مقداردهی اولیه می‌کند
downstream Est را به tunnel قبلی می‌فرستد

این Est سیگنال شروع ارسال برای TesterClient است.

در packet mode، packet-init-on-start=true می‌تواند هنگام راه‌اندازی state مربوط به packet line هر worker را مقداردهی کند؛ این حالت زمانی لازم است که packet-side Init به‌طور طبیعی به TesterServer نمی‌رسد.

بررسی درخواست

در stream mode:

byteهای درخواست در buffer جمع می‌شوند
chunkهای کامل به‌ترتیب بررسی می‌شوند
هر byte اضافه پس از sequence مورد انتظار تست را ناموفق می‌کند
پس از بررسی کامل درخواست، سمت response آماده ارسال می‌شود

در packet mode:

هر request packet باید با chunk مورد انتظار یکسان باشد
با packet-ipv4، هر packet باید یک packet کامل و non-fragmented از نوع IPv4 با مبدأ، مقصد، protocol و transport header تنظیم‌شده باشد
هر request معتبر یک response قطعی را در صف می‌گذارد
packet line باید در تمام زمان اجرا زنده بماند

با packet-stateless=true، chunkها بر اساس اندازه packet شناسایی می‌شوند و در نتیجه درخواست‌ها می‌توانند خارج از ترتیب برسند. این گزینه برای مسیرهای stateless packet مفید است که ترتیب را حفظ نمی‌کنند.

ارسال پاسخ

در stream mode، پاسخ‌ها با tunnelPrevDownStreamPayload() در جهت downstream برمی‌گردند. اگر streaming-response=false باشد، پاسخ تا بررسی کامل sequence درخواست نگه داشته می‌شود. با مقدار true، هر chunk به‌محض بررسی request chunk متناظر قابل ارسال است.

در packet mode، جهت پاسخ به سمتی بستگی دارد که درخواست از آن رسیده است:

درخواست upstream پاسخی در جهت downstream می‌گیرد
درخواست downstream پاسخی در جهت upstream و به سمت next می‌گیرد

همین رفتار استفاده از topologyهای bridged packet را ممکن می‌کند.

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

Finish

در stream mode، دریافت Finish پیش از بررسی کامل درخواست یا پیش از ارسال کامل پاسخ خطاست. پس از یک exchange موفق، upstream Finish فقط state محلی tester را از بین می‌برد.

در packet mode، دریافت Finish روی packet line در زمان اجرا یک bug است. packet lineها ابزارهای ماندگار هر worker هستند و نباید هنگام تست بسته یا از بین برده شوند.

مشخصات Node

ویژگی	مقدار
Normal position	Chain end
Packet-mode position	Chain end یا participant در مسیر bridged packet
`next`	فقط با `packet-mode=true`
Normal line ownership	line سمت client را نمی‌سازد
Packet mode	از packet line هر worker استفاده می‌کند و نباید آن‌ها را از بین ببرد
Required left padding	`0`

خطاهای رایج

استفاده به‌عنوان سرویس production؛ این نود peer مخصوص آزمایش است و در صورت mismatch برنامه را متوقف می‌کند.
اضافه کردن next در stream mode؛ next فقط با packet-mode=true پشتیبانی می‌شود.
فعال کردن packet mode بدون packet-layer node در chain.
انتظار بسته شدن packet line در packet mode.
ترکیب packet-stateless=true با max-payload-size.
استفاده از packet-ipv4 بدون packet-mode=true.

جایگاه رایج​

نمونه تنظیم​

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

تنظیمات​

جدول chunkها​

حالت Packet IPv4​

جریان اجرا​

بررسی درخواست​

ارسال پاسخ​

Finish​

مشخصات Node​

خطاهای رایج​

جایگاه رایج

نمونه تنظیم

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

تنظیمات

جدول chunkها

حالت Packet IPv4

جریان اجرا

بررسی درخواست

ارسال پاسخ

Finish

مشخصات Node

خطاهای رایج