NetBIOS په VPN کې: نوم، ډیټاګرام او سیشن بېل بېل خدمتونه دي
د روټرونو په اړه شعار ډېر پراخ دی۔ وګورئ چې ستاسو اپلیکیشن له دریو خدمتونو کوم یو کاروي، او نومونه په خپرېدنه یا د سرور له لارې حل کوي۔
«NetBIOS له روټرونو نه تېرېږي» دا خبره داسې تکرارېږي لکه څنګه چې ډیزاین یې حل کړی وي۔ خو نه یې دی حل کړی۔ د خپرېدنې له لارې د نوم پلټنه معمولاً په خپله خپرېدنه سیمه کې پاتې کېږي، مګر د NetBIOS خدمتونه کولای شي لارښود شوي IP ترافیک هم وکاروي چې په بشپړ ډول ښه روټ کېږي۔ ګټور پوښتنه دا نه ده چې NetBIOS له روټرونو تېرېږي که نه؛ پوښتنه دا ده چې ستاسو اپلیکیشن د هغې له دریو خدمتونو کوم یو کاروي۔
یو سافټویر انټرفیس، نه یو تار پروتوکول
RFC 1001 NetBIOS د یوې انټرفیس په توګه بیانوي چې اپلیکیشنونه پر هغې پروګرام لیکي، او لاندې یې څو لېږدونه دي۔ د هغې TCP/UDP ماډل د نوم خدمت، د ډیټاګرامونو وېش او د سیشن خدمت بېلوي، او په څرګنده توګه د IP خپرېدنې سره یا پرته کار کول ملاتړ کوي۔
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
همدا جدول ښیي چې شعار ولې ناکامېږي۔ د دوو نومول شوو هوسټونو ترمنځ د سیشن خدمت یو IP خبرې اترې دي؛ د خپرېدنې ډیټاګرام نه دی۔ یو VPN ډیزاین لومړی پوره کولای شي او دویم نه، او هغه ازموینه چې لومړی ثابتوي د دویم په اړه هیڅ نه وایي۔
د نوډ ډولونه ټاکي چې کلاینټ څه غواړي
په RFC 1001 کې د خپرېدنې، نقطې-تر-نقطې او ګډو نوډونو ماډلونه بیانوي چې یو هوسټ نومونه څنګه حل کوي: له سیمه ییزې شبکې پوښتنې کولو سره، له نوم سرور څخه مستقیمې پوښتنې سره، یا د یو هڅه کولو او بیا د بل سره۔ ماډل په دې اغېزه کوي چې کوم ترافیک باید اجازه ولري، نه په دې چې اپلیکیشن په بشپړ ډول کار کوي که نه۔
اداره شوې نوم-سرور ترتیبه کلاینټونو ته نقطه-تر-نقطې لار ورکوي، مګر یوازې هغو کلاینټونو ته چې د هغې کارولو لپاره تنظیم شوي۔ په شبکه کې چېرې چې سرور ایښودل اپلیکیشن هغه ته مشوره ورکولو ته نه اړ کوي، او په خپرېدنه حالت کې پرېښودل شوی کلاینټ به سیمه ییز برخې ته پوښتنې ته دوام ورکړي او د وخت پای ته ورسیږي۔ د سرور پته باید د کلاینټ تر تنظیماتو ورسېږي، د هغې اداره کولو لارې له مخې چې هغه کلاینټ یې درناوی کوي۔
نو د اړوند اپلیکیشن لپاره درې کتنې ولیکئ: څنګه د سرور نوم پتې ته اړوي، آیا کشف یا پیغام لېږل خپرېدنه یا لارښوده پای ټکی کاروي، او ریښتینی سیشن کومه پته او لېږد کاروي۔ دا خپلواک حقایق دي، او هر یو خپل حل لري۔ یو بریالي نوم-حل یوازې د لومړي په اړه شاهد دی۔
په TCP/IP باندې NetBIOS، NetBEUI نه دی
دواړه ګډوډېږي ځکه چې دواړه زاړه بلل کېږي۔ په TCP/IP باندې NetBIOS خپل خدمتونه د IP پاکټونو دننه وړي، چې لارښوده تونل دمخه یې لېږدوي۔ NetBEUI د طبقې 2 پروتوکول دی چې لارښودل کېدای نه شي، او IP تونل یوازې د دې لپاره چې IP وړي هر ډول ایټرنېټ فریمونه نه وړي۔
د IP لارې زیاتول نشي کولای چې غیر IP فریم په IP اپلیکیشن بدل کړي۔ که اپلیکیشن په رښتیا د طبقې 2 چلند پورې تړلی وي، انتخابونه په څرګنده محدود د طبقې 2 خدمت یا د اپلیکیشن بدلول دي؛ هیڅ د لارښوونې بدلون د دواړو له یوه هم نه بدلوي۔
هغه تر ټولو کوچنی بدلون وټاکئ چې دنده پوره کوي
منل شوی DNS نوم او څرګنده UNC لاره چې رسېدل کېږي موجود SMB شریکېدنه د ایټرنېټ پراخولو ته اړتیا نه لري۔ د فایل خدمت دنده او د براوز کولو تجربه بېلې اړتیاوې دي، او یوازې دویمه د ګاونډیانو لیست پورې تړلې ده۔ شریکېدنې ته په نوم رسېدل کار د خپرېدنه سیمه له تونل څخه تېرولو پرته حل کوي۔
براوز کول هغه برخه ده چې معمولاً ناکامېږي، او په چوپتیا ناکامېږي۔ ماشین کولای شي شریکېدنه د لارې له مخې پرانیزي پداسې حال کې چې د نږدې کمپیوټرونو لیست خالي پاتې کېږي، ځکه لیست د خپرېدنې کشف څخه ډکیږي او لاره DNS کاروي۔ دا چې تاسو لیست ته اړتیا لرئ، له دې څخه بېله اړتیا ده چې تاسو فایل ته اړتیا لرئ۔ مخکې له دې چې هر څه ډیزاین کړئ ولیکئ چې کاروونکي په رښتیا کومه غوښتنه کړې وه۔
کله چې زوړ اپلیکیشن په رښتیا خپرېدنه یا غیر IP فریمونه غواړي، له نوم لرونکي مالک سره محدوده د طبقې 2 خدمت ارزونه کړئ، یا اپلیکیشن بدل کړئ۔ پل ګډ ناکامي سیمه او د تګلارې پوله پراخوي، او دا NetBIOS لیکل شوی چیک بکس نه دی، د معمارۍ پرېکړه ده۔ هغه مشخص عملیات ولیکئ چې تونل باید یې ولېږدوي، بیا به مدیر وکولای شي د «ټول Windows شبکه» په اړه اټکل کولو پرځای غوښتنه ارزونه کړي۔