Bgp4Server

Bgp4Server همتای سمت سرور Bgp4Client است. فریم‌های شبیه BGP را که از سمت کلاینت و در جهت upstream می‌رسند باز می‌کند و payloadهای downstream را در جهت عکس داخل همان نوع فریم قرار می‌دهد.

این نود باید با Bgp4Client استفاده شود:

TcpListener -> Bgp4Client -> ... -> Bgp4Server -> TcpConnector

هشدار

Bgp4Server مسیریابی واقعی BGP، برقراری BGP peering، تبادل route یا احراز هویت BGP را پیاده‌سازی نمی‌کند. این نود فقط فریم‌بندی شبیه BGP ساخته‌شده توسط Bgp4Client را می‌شناسد.

این نود چه می‌کند؟

• هنگام init در جهت upstream، برای هر line یک stream خواندن و state مربوط به اولین فریم را مقداردهی اولیه می‌کند.
• نخستین فریم upstream باید فریم ساختگی OPEN از Bgp4Client باشد.
• اطلاعات BGP و body ساختگی OPEN را از فریم نخست حذف می‌کند.
• marker، length و type را از فریم‌های بعدی upstream برمی‌دارد.
• payloadهای بازیابی‌شده upstream را به تونل بعدی می‌فرستد.
• پیش از فرستادن payloadهای downstream به تونل قبلی، آن‌ها را در فریم‌های شبیه BGP قرار می‌دهد.
• در صورت دریافت فریم نامعتبر، هر دو جهت را می‌بندد.

Bgp4Server یک تونل stream معمولی است. Socket شبکه یا packet line نمی‌سازد و packet lineای را نیز آزاد نمی‌کند.

نمونه تنظیم

سمت سرور:

{
  "name": "bgp4-server",
  "type": "Bgp4Server",
  "settings": {
    "password": "compat-value"
  },
  "next": "target"
}

سمت کلاینت متناظر:

{
  "name": "bgp4-client",
  "type": "Bgp4Client",
  "settings": {
    "password": "compat-value"
  },
  "next": "transport-out"
}

فیلد password برای سازگاری با پیکربندی‌های قدیمی پذیرفته می‌شود، اما منطق فعلی پروتکل از آن برای رمزنگاری یا احراز هویت استفاده نمی‌کند.

فیلدهای اجباری

فیلدهای سطح اصلی:

فیلد	نوع	توضیح
name	string	نام یکتای نود در پیکربندی.
type	string	باید دقیقاً "Bgp4Server" باشد.
next	string	نود stream بعدی که payloadهای بازشده upstream را می‌گیرد.

تنظیمات اختیاری

گزینه	نوع	پیش‌فرض	توضیح
password	string	"passwd"	فیلد سازگاری. هنگام راه‌اندازی hash می‌شود، اما منطق فعلی فریم‌بندی از این hash استفاده نمی‌کند.

در حال حاضر تنظیم دیگری خوانده نمی‌شود.

فرمت فریم

Bgp4Server همان قالب فریم شبیه BGP را می‌خواند و می‌نویسد که Bgp4Client تولید می‌کند:

16-byte marker | 2-byte body length | 1-byte BGP type | body

جزئیات فیلد:

فیلد	مقدار
marker	شانزده بایت با مقدار 0xff.
body length	یک uint16_t با ترتیب big-endian؛ شامل بایت type به‌علاوه بایت‌های body.
BGP type	نخستین فریم upstream باید 1 باشد؛ فریم‌های downstream یکی از مقادیر تصادفی 2 تا 5 را می‌گیرند.
body	payload تونل‌شده؛ در نخستین فریم upstream شامل body ساختگی OPEN و سپس payload تونل‌شده است.

مقادیر نوع پشتیبانی‌شده:

نوع	نام
1	OPEN
2	UPDATE
3	NOTIFICATION
4	KEEPALIVE
5	ROUTE-REFRESH

فیلد length طول قالب شبیه BGP در تونل WaterWall را نشان می‌دهد، نه طول استاندارد پیام BGP. این طول، بایت type و بایت‌های body را در بر می‌گیرد، اما marker و خود فیلد length را حساب نمی‌کند.

اولین Upstream Frame

نخستین فریم upstream باید type برابر 1 داشته باشد و شامل body ساختگی OPEN و سپس بایت‌های payload تونل‌شده باشد.

Bgp4Server برای نخستین فریم:

1. بررسی می‌کند که فریم دست‌کم یک بایت type و ده بایت headerِ OPEN داشته باشد.
2. بررسی می‌کند که type برابر OPEN باشد.
3. optional parameter length را از OPEN header می‌خواند.
4. طول کامل پیشوند ساختگی OPEN را حساب می‌کند.
5. اگر پس از پیشوند OPEN هیچ payload تونل‌شده‌ای باقی نمانده باشد، فریم را رد می‌کند.
6. دریافت OPEN را در state مربوط به line ثبت می‌کند.
7. type و پیشوند OPEN را حذف می‌کند.
8. payload باقی‌مانده را در جهت upstream می‌فرستد.

از فریم‌های بعدی upstream فقط type یک‌بایتی حذف می‌شود. Body بازیابی‌شده نباید خالی باشد.

Downstream Wrapping

Payloadهای downstream پیش از ارسال به تونل قبلی، فریم‌بندی می‌شوند.

Bgp4Server از یک نوع BGP غیر-OPEN تصادفی برای frameهای payload downstream استفاده می‌کند:

2, 3, 4, or 5

این نود payload را رمزنگاری یا احراز هویت نمی‌کند؛ فقط آن را در فریم قرار می‌دهد.

محدودیت‌ها و Padding

مقدار	مقدار	یادداشت
حداکثر طول body	65535 بایت	شامل type یک‌بایتی.
حداکثر payload در body عادی	65534 بایت	مجموع payload و type باید در 65535 بایت جا شود.
حداکثر بایت در بافر خواندن	حدود 131106 بایت	معادل دو پیام فریم‌شده با بیشترین اندازه.
required_padding_left	19 بایت	برای marker، length و type فریم.

اگر payloadِ downstream در یک فریم شبیه BGP جا نشود، رد می‌شود و فریمی فرستاده نخواهد شد.

جریان داده

جهت upstream:

previous node -> Bgp4Server unwraps -> next node

جهت downstream:

next node -> Bgp4Server wraps -> previous node

سمت upstream باید فریم‌های تولیدشده توسط Bgp4Client را دریافت کند. اگر نخستین فریم upstream همان فریم ساختگی OPEN مورد انتظار نباشد، line بسته می‌شود.

رفتار Lifecycle

با دریافت init در جهت upstream، Bgp4Server state مربوط به line را مقداردهی اولیه می‌کند و init را در همان جهت به تونل بعدی می‌فرستد.

با دریافت est در جهت downstream، آن را به تونل قبلی می‌فرستد.

Payloadهای upstream را بافر، parse و اعتبارسنجی می‌کند، فریم را باز می‌کند و داده بازیابی‌شده را به تونل بعدی می‌فرستد. Payloadهای downstream را فریم‌بندی و به تونل قبلی ارسال می‌کند.

با دریافت finish از هر جهت، state مربوط به line را از بین می‌برد و finish را در همان جهت منتشر می‌کند: در upstream به تونل بعدی و در downstream به تونل قبلی.

در صورت دریافت فریم نامعتبر، Bgp4Server state محلی را از بین می‌برد و هر دو جهت را با ترتیب لازم برای یک تونل میانی می‌بندد: ابتدا finish در upstream و سپس finish در downstream.

Pause و resume در همان جهت دریافت‌شده عبور داده می‌شوند:

Callback	مقصد ارسال
upstream pause/resume	next tunnel upstream
downstream pause/resume	previous tunnel downstream

نکته‌ها

• برای استفاده عملی از Bgp4Server باید آن را با Bgp4Client جفت کنید.
• در پیاده‌سازی فعلی، password قابلیت امنیتی محسوب نمی‌شود.
• نخستین فریم upstream باید یک فریم OPEN باشد که پس از body ساختگی OPEN، payload تونل‌شده داشته باشد.
• فیلد طول در قالب شبیه BGP، بایت‌های marker و length را در نظر نمی‌گیرد.
• upstream est و downstream init غیرفعال هستند.
• این نود یک تونل stream لایه ۴ است، نه packet tunnel.