این جمله که «NetBIOS از مسیریاب‌ها عبور نمی‌کند» طوری تکرار می‌شود که گویی تکلیف طراحی را روشن کرده است. روشن نکرده است. جست‌وجوی نام با پخش همگانی معمولاً درون دامنه پخش خودش می‌ماند، اما سرویس‌های NetBIOS می‌توانند از ترافیک IP جهت‌دار هم استفاده کنند که کاملاً درست مسیریابی می‌شود. پرسش سودمند این نیست که آیا NetBIOS از مسیریاب‌ها عبور می‌کند؛ پرسش این است که برنامه شما کدام یک از سه سرویس آن را به کار می‌برد.

یک واسط نرم‌افزاری، نه یک پروتکل سیمی واحد

RFC 1001 پروتکل NetBIOS را واسطی توصیف می‌کند که برنامه‌ها روی آن برنامه‌نویسی می‌کنند، با چند لایه انتقال در زیر آن. مدل TCP/UDP آن سرویس نام، توزیع دیتاگرام و سرویس نشست را از هم جدا می‌کند و صراحتاً کارکردن با یا بدون پخش همگانی IP را پشتیبانی می‌کند.

ServiceWhat it doesTransport dependence
NameRegisters and resolves namesBroadcast, point-to-point, or a name server
DatagramConnectionless messages, including broadcastBroadcast domain or directed delivery
SessionConnection-oriented exchangeTCP connection to a named endpoint

همین جدول نشان می‌دهد چرا شعار شکست می‌خورد. سرویس نشست میان دو میزبان نام‌دار یک گفت‌وگوی IP است؛ دیتاگرام پخش همگانی چنین نیست. یک طراحی VPN می‌تواند اولی را برآورده کند و دومی را نه، و آزمونی که اولی را ثابت می‌کند درباره دومی چیزی نمی‌گوید.

نوع گره تعیین می‌کند مشتری چه می‌خواهد

مدل‌های گره پخش همگانی، نقطه‌به‌نقطه و مختلط در RFC 1001 توضیح می‌دهند که یک میزبان چگونه نام‌ها را حل می‌کند: با پرسیدن از شبکه محلی، با پرسیدن مستقیم از سرور نام، یا با آزمودن یکی و سپس دیگری. مدل بر این اثر می‌گذارد که چه ترافیکی باید مجاز باشد، نه بر اینکه برنامه اصلاً کار می‌کند یا نه.

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

پس سه مشاهده برای برنامه موردنظر ثبت کنید: چگونه نام سرور را به نشانی تبدیل می‌کند، آیا کشف یا پیام‌رسانی از پخش همگانی استفاده می‌کند یا از یک نقطه پایانی جهت‌دار، و نشست واقعی از چه نشانی و چه وسیله نقلی استفاده می‌کند. این‌ها واقعیت‌های مستقل‌اند و هر کدام راه‌حل خودش را دارد. یک بار موفق حل نام تنها درباره اولی شاهد است.

NetBIOS روی TCP/IP همان NetBEUI نیست

این دو را با هم اشتباه می‌گیرند چون به هر دو «کهنه» می‌گویند. NetBIOS روی TCP/IP سرویس‌هایش را درون بسته‌های IP می‌برد، که یک تونل مسیریابی‌شده از پیش آن‌ها را حمل می‌کند. NetBEUI پروتکلی در لایه 2 است که مسیریابی نمی‌شود، و تونل IP فقط به این دلیل که IP حمل می‌کند، قاب‌های دلخواه اترنت را حمل نمی‌کند.

افزودن یک مسیر IP نمی‌تواند قابی غیر از IP را به برنامه‌ای IP تبدیل کند. اگر برنامه‌ای واقعاً به رفتار لایه 2 وابسته باشد، گزینه‌ها یک سرویس لایه 2 با محدوده صریح است یا جایگزینی برنامه؛ هیچ تغییر مسیریابی جای هیچ‌کدام را نمی‌گیرد.

کوچک‌ترین تغییری را انتخاب کنید که کار را برآورده می‌کند

یک اشتراک SMB موجود که با نام DNS تأییدشده و مسیر UNC صریح به‌دست می‌آید به گسترش اترنت نیازی ندارد. کار سرویس فایل و تجربه مرور دو نیاز متفاوت‌اند و تنها دومی به فهرست همسایه‌ها وابسته است. رسیدن به اشتراک با نام، کار را بی‌آنکه دامنه پخش همگانی را از میان تونل بکشیم حل می‌کند.

مرور همان بخشی است که معمولاً شکست می‌خورد، و بی‌صدا شکست می‌خورد. یک ماشین می‌تواند اشتراک را با مسیر باز کند در حالی که فهرست رایانه‌های نزدیک خالی می‌ماند، چون فهرست با کشف پخش همگانی پر می‌شود و مسیر از DNS استفاده می‌کند. تصمیم اینکه به فهرست نیاز دارید، نیازی متفاوت از تصمیم اینکه به فایل نیاز دارید است. پیش از طراحی هر چیزی بنویسید کاربر واقعاً کدام را خواسته است.

وقتی برنامه‌ای کهنه واقعاً به پخش همگانی یا قاب‌های غیر IP نیاز دارد، یک سرویس لایه 2 محدود با مالک نام‌دار را ارزیابی کنید یا برنامه را جایگزین کنید. یک پل دامنه خرابی مشترک و مرز سیاست را گسترش می‌دهد، و این یک تصمیم معماری است نه یک کادر تیک با برچسب NetBIOS. عملیات مشخصی را که تونل باید حمل کند مستند کنید، تا مدیر بتواند درخواست را ارزیابی کند نه اینکه درباره «کل شبکه ویندوز» حدس بزند.

مقالات مرتبط