Java DatagramSocket و بازپخش UDP با SOCKS5
درک کنید چرا یک سوکت UDP در جاوا به پیاده‌سازی SOCKS5 UDP نیاز دارد، حتی وقتی اتصال‌های TCP از پیش از SOCKS استفاده می‌کنند.
درخواست HTTP جاوای شما از طریق SOCKS کار می‌کند، اما یک قابلیت UDP همچنان ترافیک را مستقیم می‌فرستد یا شکست می‌خورد. تنظیم ویژگی‌های SOCKS در JVM به DatagramSocket پیاده‌سازی SOCKS5 UDP نمی‌دهد.
API DatagramSocket داده‌نگاره‌های نشانی‌دهی‌شده به نقاط پایانی شبکه را می‌فرستد و می‌گیرد. متد connect() آن یک همتا برای آن سوکت انتخاب می‌کند. این متد هیچ مذاکره SOCKS با همتا انجام نمی‌دهد.
مسیر UDP روی SOCKS5 کار بیشتری می‌خواهد
SOCKS5 یک پیوند UDP که روی یک اتصال کنترل TCP برقرار می‌شود تعریف می‌کند. سپس کارخواه داده‌نگاره‌های کپسوله‌شده را با نشانی بازپخش که پروکسی می‌دهد مبادله می‌کند. هر پیام کپسوله‌شده مقصد خود را مشخص می‌کند. پیاده‌سازی کارخواه باید این قالب‌بندی و طول عمر اتصال کنترل را مدیریت کند.
نشانه‌رفتن یک سوکت UDP معمولی به درگاه شنود TCP پروکسی از این گام‌ها می‌گذرد. فرستادن داده‌نگاره‌های خام برنامه شما به آن نشانی جایگزین پیوند نیست.
یک کتابخانه یا قابلیت برنامه انتخاب کنید که صریحاً بازپخش UDP روی SOCKS5 را پشتیبانی می‌کند و تأیید کنید که سرور هم آن را پشتیبانی می‌کند. کتابخانه‌ای که پشتیبانی SOCKS را تبلیغ می‌کند ممکن است فقط TCP CONNECT را پیاده کرده باشد. مشخصات پروتکل میان این فرمان‌ها تفاوت می‌گذارد.
بازپخش UDP هم به مسیری قابل استفاده نیاز دارد
یک اتصال TCP موفق به پروکسی تنها مسیر کنترل را برقرار می‌کند. دیوارهای آتش یا رفتار NAT همچنان می‌تواند با داده‌نگاره‌های فرستاده‌شده به بازپخش تداخل کند. نقطه پایانی بازپخش برگشتی و هر خطای بازپخش را جمع کنید پیش از آنکه نتیجه بگیرید مقصد برنامه از دسترس خارج است.
در پایان، پشتیبانی انتقال SOCKS هیچ تضمین تحویلی به UDP نمی‌افزاید. مهلت‌های خود برنامه شما، مدیریت افتادگی و محدودیت‌های اندازه پیام پس از تغییر مسیر هم چنان برقرارند.