NetBIOS över TCP/IP (NetBT) är en nätverkstjänst på sessionsnivå som kopplar namn till IP-adresser. I SunLink Server implementeras NetBT genom WINS och koppling genom massutsändning av namn. De två viktigaste aktiviteterna är hur namn registreras och kopplas:
Registrering innebär att man registrerar ett unikt namn för varje dator (nod) på nätverket. I typfallet registrerar en dator sig själv när den startar.
Koppling innebär att den specifika adressen för ett datornamn bestäms.
RFC 1001 och 1002 anger hur NetBIOS bör implementeras över TCP/IP och definierar funktionslägena för koppling av namn till IP-adresser.
I NetBT definieras funktionslägen som anger hur man identifierar och kommer åt nätverksresurser. De funktionslägen i NetBT som stöds av SunLink Server är:
b-nod - Använder massutsändning av meddelanden för att koppla namn
h-nod - Använder först en annan typ av nod för namnfrågor, och därefter b-nod om namntjänsten inte är tillgänglig eller om namnet inte är registrerat i databasen
RFC hänför sig till NetBIOS Name Server (NBNS). WINS är en utökning av NBNS.
De båda vanligaste nodtyperna för Windows-klientdatorer är b-nod och h-nod.
DHCP-användare kan få nodtypen tilldelad av DHCP-servern (beroende på hur klienten konfigurerats). När det finns WINS-servrar på nätverket kopplar NetBT namn på en klientdator genom att kommunicera med WINS-servern. När det inte finns några WINS-servrar, massutsänder NetBT meddelanden i b-nod för att avbilda namn. NetBT kan även använda LMHOSTS-filer för koppling av namn, beroende på hur TCP/IP är konfigurerat på en viss dator.
SunLink Server kan fungera med NetBT-lägena b-nod och h-nod.
I b-nod används massutsändningar för att registrera och avbilda namn. Om exempelvis KLIENT_PC1 vill kommunicera med KLIENT_PC2, gör den en massutsändning till samtliga datorer att den letar efter KLIENT_PC2. Den väntar sedan en angiven tid på att KLIENT_PC2 skall svara.
Det finns två stora problem med b-nodsläget:
I en stor miljö belastas nätverket av massutsändningarna.
I typfallet sänder dirigerare inte massutsändningar vidare. Om två datorer befinner sig på var sin sida av en dirigerare kommer de därför aldrig att höra anropen.
H-nodsläget löser de viktigaste problemen med massutsändningsmeddelanden och dirigerade miljöer. Det kombinerar b-nod och en annan nodtyp där massutsändningsmeddelanden utnyttjas som en sista utväg. Om WINS-servern är avstängd--vilket gör det absolut nödvändigt med massutsändning av meddelanden--fortsätter datorn att försöka kolla om WINS-servern är igång tills den kan nås igen. H-nod kan även konfigureras så att den utnyttjar filen LMHOSTS efter det att koppling av namn med massutsändning misslyckats.
Det skapas inte några massutsändningsmeddelanden om WINS-servern är igång, och datorerna kan ligga på var sin sida av dirigerarna. Om WINS-servern är avstängd används b-nod, och datorer som ligger på samma sida om en dirigerare kan fortsätta arbeta som vanligt.
För Microsoft TCP/IP-användare som konfigurerar TCP/IP manuellt gäller att h-nod används som standard, förutsatt att användaren angivit några adresser till WINS-servrar när TCP/IP konfigurerades.
En annan variation, så kallad modifierad b-nod, används i SunLink Server-nätverk för att låta meddelanden passera dirigerare. I modifierad b-nod används det inte någon WINS-server. I detta funktionsläge använder b-nod en lista med datorer och adresser lagrad i en LMHOSTS-fil. Om ett b-nodsförsök misslyckas, tittar systemet i LMHOSTS efter ett namn och använder sedan motsvarande adress för att passera dirigeraren. Emellertid måste listan finnas på alla datorer, vilket gör administrationen mer omfattande genom att listan måste uppdateras och distribueras.
Windows for Workgroups 3.11 använder ett modifierat b-nodssystem. Windows NT utnyttjar denna metod om det inte används några WINS-servrar på nätverket. I Windows NT har formatet för filen utökats litet för att göra den lättare att hantera--men modifierad b-nod är inte någon idealisk lösning.