این صفحه برای کسی است که میخواهد بداند دقیقاً چه کاری انجام میشود و هر عددی که ادعا میکنیم از کجا آمده.
هر بستهٔ UDP همزمان از چند مسیر فرستاده میشود، با یک شمارهٔ ترتیب یکسان. سمت گیرنده اولین نسخهای که برسد تحویل داده میشود و بقیه دور ریخته میشوند. خود تونل برای UDP بازفرست نمیکند؛ بستهٔ دیررس ممکن است دیگر برای همان لحظهٔ بازی کاربردی نداشته باشد. جریانهای TCP سازوکار اطمینان و بازفرست خود را دارند.
مسیریابی بر اساس مقصد است، نه بر اساس برنامه: وصل برای نشانی سرورهای همان بازی route میزبان نصب میکند و ویندوز هرچه به آن نشانیها برود از این کارت میفرستد. پس دقیقتر این است که بگوییم «ترافیک به مقصد سرورهای این بازی»، نه «ترافیک این بازی» — اگر برنامهٔ دیگری هم به همان نشانی وصل شود، از همین مسیر میرود. هیچ route پیشفرضی نصب نمیشود، پس بقیهٔ اینترنت دستنخورده است.
در نسخهٔ 0.7.29، ترافیک مقصدهای IPv4 مسیریابیشده دو مسیر حمل دارد: UDP از تونل بستهای میگذرد و TCP با یک اتصال رمزگذاریشدهٔ TLS به رله حمل میشود. اتصال TCP در کلاینت دریافت میشود و رله یک اتصال جدا به مقصد اصلی باز میکند. گواهی TLS رله با اثرانگشتی که پنل اعلام میکند بررسی میشود؛ بدون نشانی و اثرانگشت معتبر، مسیر TCP قابل استفاده نیست.
این پشتیبانی مربوط به مقصدهای IPv4 است؛ IPv6 داخل تونل حمل نمیشود. اتصال بیرونی به رله میتواند IPv4 یا IPv6 باشد، اما این به معنی پشتیبانی از مقصد IPv6 نیست. تفکیک بر اساس پروسه نیز انجام نمیشود؛ تمام برنامههایی که به همان مقصد مسیریابیشده وصل شوند از همان مسیر استفاده میکنند. آزمون نهایی این نسخه روی ویندوز و سنجش کیفیت در بازی واقعی هنوز تأیید نشده است.
این 0.25% یک حساب است، نه یک اندازهگیری: 5% ضرب در 5%، با این فرض که دو
مسیر کاملاً مستقلاند. مسیرهای واقعی تا حدی مشترکاند — همان کارت شبکه، همان
ISP، بخشی از همان راه — پس نتیجهٔ واقعی از این عدد بدتر است و به میزان
استقلال دو مسیر بستگی دارد.
MTU تونل 1380 بایت است تا بسته بعد از افزودهشدن سرآیندها همچنان بدون
قطعهشدن از مسیر رد شود.
مسیر بستهای UDP حلقهٔ کنترل ازدحام ندارد. چیزی که دارد یک سطل توکن با نرخ ثابت است: نرخ پیکربندیشده، سقف انفجار محدود، و وقتی سطل خالی است بسته دور ریخته میشود، نه صف میشود — صفکردن یک محدودیت نرخ را به تأخیر تبدیل میکند و بستهٔ بازی که منتظر بماند تا آن موقع بیارزش شده. این سازوکار برای پیداکردن ظرفیت مسیر نیست؛ برای این است که یک نشست خراب نتواند لینک را پر کند.
راهنمای مرجع این کار RFC 8085 است، بخش 3.1 و بهویژه 3.1.11 دربارهٔ تونلهای UDP: تونلی که ترافیکِ خودش کنترلشده را حمل میکند لازم نیست کنترل ازدحام دومی بگذارد، ولی تونل باید سقف نرخ یا circuit breaker داشته باشد. ترافیک بازی کمنرخ و تقریباً ثابت است و خود بازی آن را تنظیم میکند؛ سقف اینجا همان سطل توکن است.
محدودیتهایش را هم بنویسیم، چون واقعیاند. این کنترل ازدحام نیست: وصل در ازدحام عقب نمیکشد، پس به بازیابی لینک کمکی نمیکند و میتواند نسبت به جریانهای TCP که عقب میکشند سهم بیشتری بردارد. چند مسیر همزمان یعنی بار ضرب در تعداد مسیرها. سقف ثابت است و کشف نمیشود، پس روی لینکی کندتر از سقف، نتیجه فقط دورریختن بسته است. و امروز circuit breaker ی وجود ندارد که در اضافهبار مداوم نشست را قطع کند — تنها مرز، همان سطل است.
دو مسیر یعنی دو برابر پهنای باند برای همان بازی. ترافیک بازیهای رقابتی کوچک است (معمولاً زیر 100 کیلوبیت بر ثانیه در هر جهت)، ولی روی اینترنت حجمی این ضرب واقعی است و در برنامه قابل تنظیم: یک، دو یا سه مسیر.
برنامه تأخیر رفتوبرگشت تا رله را اندازه میگیرد، نه تا سرور بازی: بخش آخر مسیر — از رله تا سرور بازی — با پروبهای محدودشدهٔ خود والو فقط از نظر زندهبودن دیده میشود و برایش عدد گمشدن و نوسان نوشته نمیشود. پینگی که داخل بازی میبینید مجموع کل مسیر است و معمولاً از عدد داخل وصل بزرگتر درمیآید، چون یک پارهٔ بیشتر را در بر میگیرد. «همیشه» نیست: دو عدد را دو چیز مختلف در دو لحظهٔ مختلف اندازه میگیرند و بازیها هم آن را هموار میکنند، پس مقایسهشان یک قاعده نیست.