Pierwsze opracowania dotyczące SMB pojawiają się w 1985 roku.
SaMBa w kolejnych latach była rozwijana przez Microsoft oraz inne korporacje.
SaMBa to protokół dzięki któremu możemy współdzielić zasoby.
Komunikuje się przez protokoły TCP/IP, NetBEUI (w obydwu przypadkach korzysta z NetBios API), oraz IPX/SPX.
Działa w architekturze klient - serwer, zgodnie z metodą żądanie - odpowiedź (request - response).
Korzystanie z SMB poprzez komendy (zwane SaMBami (SMBs)...).
Nazwy mają 15 liter. Najczęściej jest to nazwa komputera.
Microsoft (i niektórzy inni) wymagają, żeby nazwy były pisane wielkimi literami.
Podczas transmisji dodawany jest 16 znak , tzw. sufix, oznaczający typ nazwy.
W standardzie występują dwa typy nazw NetBIOSu: Unique oraz Global.
Microsoft rozszerza standard o kolejne typy: Internet Group, Domain, Multihomed.
Pierwszym wariantem protokołu był Core Protocol. Udostępniał następujące operacje:
| Wariant Protokołu SMB | Nazwa Protokołu | Opis |
|---|---|---|
| PC NETWORK PROGRAM 1.0 | Core Protocol | Oryginalna wersja SMB, tak jak opisana w IBM PC Network Program. Niektóre wersje nazywały się PCLAN1.0 |
| MICROSOFT NETWORKS 1.03 | Core Plus Protocol | Zawiera komendy Lock&Read oraz Write&Unlock oraz różne wersje komend zwykłego odczytu / pisania |
| MICROSOFT NETWORKS 3.0 | DOS LAN Manager 1.0 | Tak jak w LANMAN1.0, ale błędy OS/2 muszą być tłumaczone na błędy DOSowe. |
| LANMAN1.0 | LAN Manager 1.0 | Pełny protokół LANMAN1.0. |
| DOS LM1.2X002 | LAN Manager 2.0 | Tak samo jak w LM1.2X002, ale błędy muszą być tłumaczone na błędy DOSowe. |
| LM1.2X002 | LAN Manager 2.0 | Pełna wersja protokołu LANMAN2.0. |
| DOS LANMAN2.1 | LAN Manager 2.1 | Tak samo jak w LANMAN2.1, ale błędy muszą być tłumaczone na błędy DOSowe. |
| LANMAN2.1 | LAN Manager 2.1 | Pełny protokół LANMAN2.1. |
| Windows for Workgroups 3.1a | LAN Manager 2.1? | Windows for Workgroups 1.0? |
| NT LM 0.12 | NT LAN Manager 1.0? | Zawiera specjalne komendy dla NT |
| Samba | NT LAN Manager 1.0? | Wersja protokołu NT LM 0.12? opracowana przez Sambę. |
| CIFS 1.0 | NT LAN Manager 1.0 | Prawdziwy protokół NT LM 0.12 i jeszcze trochę. |
Wariant protokołu ustalany jest za pomocą komendy negprot, która musi być pierwszą komendą po nawiązaniu połączenia.
Występują dwa poziomy ochrony danych:
Serwery rozsyłają informacje o sobie.
W NetBEUI jest to wystarczające, ale w TCP/IP już nie, ponieważ w rozsyłana informacja nie wydostaje się poza podsieć, w której znajduje się nadający ją serwer.
Microsoft wprowadził serwery poszukiwań (browse servers) oraz WINS (Windows Internet Name Service) aby umożliwić rozpowszechnianie informacji o serwerach (kosztem centralizacji).
Kolejny standard opracowywany przez Microsoft (oraz Digital Equipment, Data General, Network Appliance Corp. i innych)
Publiczna wersja SMB.
Przewiduje się, że CIFS 1.0 będzie zawierał NT LM 0.12 z nieznacznymi zmianami ułatwiającymi wykorzystanie Internetu.
Składowe protokołu (żądania i odpowiedzi), które są wymieniane przez klientów i serwery nazywane są SaMBami (SMBs). Mają ściśle określony format, bardzo podobny dla żądań i odpowiedzi. Każda komenda składa się z nagłówka (ściśle określony rozmiar), a następnie parametru i danych (zmienna długość).
Po połączeniu z poziomem NetBIOS, klient jest gotowy do wymiany informacji z serwerem. Jakkolwiek najpierw klient i serwer muszą ustalić wariant protokołu.
Klient wysyła komendę negprot do serwera, wylistowując znane przez siebie dialekty. Następnie serwer odpowiada indeksem dialektu, z którego chce korzystać, bądź 0xFFFF, jeśli żaden z dialektów nie był dobry.
Dialekty nowsze niż Core i Core Plus w swojej odpowiedzi przesyłają dodatkowe informacje, które opisują serwer (wielkosc bufora, standardowe nazwy plików, itp.)
Kiedy wariant protokołu został ustanowiony klient może rozpocząć logowanie się na serwer (jeśli jest to konieczne). Wykorzystuje do tego komendę sesssetupX. Odpowiedź wskazuje czy udało się zalogować, czy nie. Może również przekazywać dodatkowe informacje. Jednym z najważniejszych fragmentów odpowiedzi jest UID zalogowanego użytkownika. Numer ten musi być przekazywany z każdą kolejną komendą przesyłaną do serwera w trakcie tego połączenia.
Kiedy użytkownik jest już zalogowany (w starszych protokołach - Core oraz Core Plus logowanie nie jest zaimplementowane), klient może przystąpić do podłączania do drzewa.
Klient wysyła komendę tcon lub tconX określającą sieć bądź udział, do którego chce się podłączyć i jeżeli wszystko jest OK, serwer odsyła TID, z którego klient będzie korzystał w przyszłych odniesieniach do tego udziału.
Po uzyskaniu dostępu do drzewa klient może korzystać z plików za pomocą odpowiednich komend (wiele komend realizujących odczyt, zapis, otwieranie, itd.).
Strony zawierające dużo informacji dotyczących SMB:
DFS potrafi przesyłać dane za pomocą różnych protokołów sieciowych.
| Ścieżka DFS | [Serwer + Udział] (lista) | Czas życia |
|---|---|---|
| Cecha | Opis | Korzyść |
|---|---|---|
| Hierarchiczny widok dzielonych zasobów | Łącząc udziały w jeden widok DFS powoduje, że dane widoczne są jakby na jednym "gigantycznym" twardym dysku. Użytkownicy mogą sami tworzyć nowe obiekty w DFSie, które mogą sami dołączać do drzewa (wewnętrzne linki DFSa) | Uproszczony widok zasobów sieciowych. Może być dostosowywany do potrzeb przez administratora |
| Łatwa administracja woluminami | Poszczególne udziały w DFSie mogą być usuwane, bądź chwilowo wyłączane bez wpływania na pozostałe zasoby | Administrator może manipulować fizycznymi danymi nie naruszając ich logicznej reprezentacji |
| Graficzne narzędzie administracyjne | Zasoby mogą być administrowane, przeglądane, zmieniane w łatwym w obsłudze środowisku graficznym | Łatwe do opanowania, co zmniejsza zapotrzebowanie na wysoko wykwalikowaną administracje non-stop |
| Większa dostępność danych | Wiele kopii tych samych danych może zostać podłączonych w to samo miejsce w DFSie (alternatywne lokacje). W przypadku utraty łączności z jedną lokacją klienci korzystają z innych | Ważne dane biznesowe są zawsze dostępne, nawet w przypadku awarii serwera, dysku, pliku |
| Balansowanie obciążenia | Alternatywne lokacje zmniejszają obciążenie dostępu do poszczególnych serwerów. Zapytania rozdzielane są pomiędzy wszystkie lokacje. | Poprawia czas odpowiedzi szczególnie w trakcie okresów szczytowego użycia sieci |
| Przezroczystość nazw | Końcowi użytkownicy poruszają się w logicznych obszarach (name-spaces), nieświadomi fizycznej lokalizacji danych. Dane mogą być przenoszone, a ustawienia serwera DFS zmienione tak, że użytkownicy nie zauważają żadnych zmian w logicznej strukturze sieci. | Zwiększona elastyczność administrowania. |
| Integracja z zabezpieczeniami Windows NT | Użytkownik podłączony do DFSa może korzystać jedynie z plików, do których ma odpowiednie prawa. | Wykorzystuje istniejące mechanizmy bezpieczeństwa Windows NT. Łatwa administracja i bezpieczny dostęp. |
| Klient DFS dołączony do Windows NT Workstation 4.0, dostępny dla Windows 95+ | wiadomo... | Korzystanie z DFSa nie wymaga żadnego dodatkowego oprogramowania w systemach klienckich |
| Cachowanie przez klienta | DFS może łączyć w sobie setki czy tysiące udziałów. Oprogramowanie klienckie cachuje niektóre informacje lokalnie. Następnym razem, kiedy klient odwołuje się do name-space'u DFS, klient sprawdza zcachowane dane, niekoniecznie sprawdza to przez sieć. | Umożliwia szybik dostęp do złożonych hierarchii zasobów sieciowych |
| Aplikacje klienckie dla Windows 95+ | Poza wyposażonym w DFSa Windowsem NT Workstation, DFS zawiera usługę umożliwiającą Windowsowi 95+ korzystanie z przestrzeni DFS. | Rozszerza DFSa na systemy Win 95+ |
| Współpracuje z innymi rozproszonymi systemami plików | Każdy udział dostępny przez przekierowanie na Windows NT Workstation może być częścią name-space'u DFSa. Przekierowanie może następować zarówno przez przekierowania klienckie (client redirectors) jak też serwerową technologię bramek. | Administrator może tworzyć pojedynczą hierarchię danych zawierającą odwołania od wielu sieciowych systemów plików |