|
|
|
|
Indice
Hasta ahora hemos visto como trabaja el ambiente Windows con el protocolo NetBIOS transportado por TCP/IP y por NetBEUI.
El interrogante es ahora si es posible que interactúen ambientes completamente diferentes, como lo son Windows y Unix; es decir que un usuario Windows pueda acceder a los servicios de un servidor Unix y de la misma forma un usuario Unix pueda acceder a los servicios de un servidor Windows.
La respuesta a este interrogante es "si" y es posible gracias a la existencia de un protocolo conocido como SMB, Server Message Block.
En lo que concierne a Windows for Workgroups, Windows 95 y Windows NT son capaces de correr SMB como un cliente, un servidor o como ambos. Para ello usan la interfaz que tienen y que es NetBIOS, siendo como ya se mencionó en trabajos anteriores los vehículos más famosos NetBEUI y TCP/IP.
En lo que respecta a la plataforma UNIX existe un producto comercial, freeware que permite esta interacción con Windows. Este producto es conocido como Samba y fue creado por Andrew Tridgeel.
SMB fue definido en un documento de Microsoft/Intel llamado Microsoft Networks / Open Net-file Sharing Protocol en el año 1.987. Sus posteriores desarrollos estuvieron a cargo de Microsoft y otros.
Este protocolo permite a una aplicación o al usuario de una aplicación compartir archivos, discos, directorios, impresoras, puertos seriales, named pipes y mail slots a través de una red. En otras palabras permite a un cliente leer, crear y modificar archivos de un servidor remoto; permitiendo de esta forma poder comunicarse con cualquier servidor, siempre y cuando este esté configurado para recibir una solicitud de un cliente SMB.
SMB se define como la estructura cliente-servidor, donde el cliente formula una solicitud y el servidor envía su respuesta ( Ver Figura 5). El servidor tiene su sistema de archivos y otros recursos tales como: impresoras, mailslots, named pipes, APIs; disponibles para los clientes sobre la red. Por su parte los clientes pueden tener su propio disco duro pero pueden también querer tener acceso al sistema de archivos e impresoras del servidor.
Los clientes se conectan al servidor usando TCP/IP, NetBEUI e IPX/SPX. Una vez que la conexión esta establecida, el cliente envía comandos (llamados SMBs) al servidor para trabajar con el sistema de archivos.
Figura 5
Con lo anterior podemos ver que SMB puede correr sobre múltiples protocolos: TCP/IP y NetBEUI con el protocolo NetBIOS e IPX/SPX. En el caso de que se este usando SMB sobre TCP/IP o NetBEUI los nombres NetBIOS tienen un largo de 15 caracteres y son generalmente el nombre de las computadoras que están corriendo NetBIOS.
Desde que SMB fue incorporado muchos han sido las variantes del protocolo que han sido desarrolladas, para poder manejar la gran y creciente complejidad de los ambientes de red.
La primer variante del protocolo fue "Corel Protocol" conocido como PC Network Program 1.0., que incluía el siguiente conjunto de operaciones:
Las otras variantes fueron introducidas a medida que se necesitaba más funcionalidad (Ver Tabla 2).
| Variante del Protocolo SMB | Nombre del Protocolo |
| PC NETWORK PROGRAM 1.0 | Protocolo Core |
| MICROSOFT NETWORKS 1.03 | Protocolo Core Plus |
| MICROSOFT NETWORKS 3.0 | DOS LAN Manager 1.0 |
| LANMAN 1.0 | LAN Manager 1.0 |
| DOS LM1.2X002 | LAN Manager 2.0 |
| LM1.2X002 | LAN Manager 2.0 |
| DOS LANMAN2.1 | LAN Manager 2.1 |
| LANMAN2.1 | LAN Manager 2.1 |
| Windows for Workgroups 3.11 | LAN Manager 2.1 |
| NT LM 0.12 | NT LAN Manager 1.0 |
| Samba | NT LAN Manager 1.0 |
| CIFS 1.0 | NT LAN Manager 1.0 |
Tabla 2
Algunas variantes introducían nuevos SMBs, algunos simplemente cambiaban el formato de los SMBs existentes o las respuestas de los servidores y algunos cambiaban ambos.
ALGUNAS DEFINICIONES A TENER EN CUENTA
Como vimos la relación entre los clientes y el servidor es a través de solicitudes que los primeros formulen a los segundos, solicitud-respuesta; estos son conocidos como los elementos del protocolo y es a este intercambio que se llama SMBs.
Los SMBs tienen un formato específico el cual es similar tanto para la solicitud como para la respuesta enviada por el servidor. Constan de una cabecera de tamaño fijo, un parámetro de tamaño variable y una porción para el dato.
Una vez que la conexión esta hecha, el cliente esta listo para solicitar los servicios al servidor siendo necesario en primera instancia que el servidor y el cliente identifiquen que variante del protocolo ellos van a usar para entenderse.
Es decir que el primer paso es que se establezca el protocolo que va a permitir que ambos se entiendan, para ello el cliente envía un negprot SMB al servidor. Allí el cliente lista los dialectos del protocolo que entiende, por su parte el servidor puede responder con el índice del dialecto que este quiere usar o con 0XFFFF en el caso que no acepte el dialecto del cliente. En caso de que el servidor acepte el dialecto la información que este suministra al cliente en el negprot response es acerca de sus capacidades (por ejemplo tamaño máximo del buffer), esto es para el caso de los dialectos más recientes que el Protocolo Core y Core Plus (Ver Figura 6).
Figura 6
Una vez que el protocolo se ha establecido, el cliente puede proceder a loguearse al servidor para lo cual utiliza un sessetupX SMB (Ver Figura 7). La respuesta del servidor indica si tiene o no un usuario válido; es decir su identificación, la cual es conocida como UID, si es así le podrá suministrar información adicional.
Figura 7
Una vez que el cliente se ha logueado con el servidor puede proceder a conectarse al sistema de archivos, para ello el cliente envía un tcon o tconX SMB donde especifica el nombre de la red al que quiere conectarse (Ver Figura 8). Conectado al sistema de archivos podrá abrir un archivo con open SMBs, leerlo con read SMBs, escribirlo con write SMBs y cerrarlo con close SMBs.
Figura 8
El modelo SMB define dos niveles de seguridad:
Lo que se plantea aquí es que si existe un grupo de servidores en la red, no es buena idea que los usuarios no puedan encontrarlos, que solamente estén configurados para conocer únicamente los servidores de su ambiente. Si esto fuera así no sería de gran ayuda cuando nuevos servidores van a ser introducidos o cuando servidores viejos van a ser removidos.
Para resolver este problema fue introducido "browsing", que lo podemos definir como el procedimiento a través del cual los servidores dan a conocer su presencia en la red utilizando para ello los broadcasts, de esta forma los clientes se enteran ya que escuchan esos broadcasts y construyen sus "browse lists".
Como ya se mencionó en un ambiente NetBEUI el envío de información a través de broadcasts es satisfactorio pero no sucede lo mismo en un ambiente TCP/IP ya que existen problemas. Ello se debe a que los broadcasts no son usualmente enviados fuera de la subred en la que son originados. Para solucionar el problema de que en este entorno no se puedan utilizar los broadcasts para que los servidores puedan anunciar su presencia en la red, Microsoft ha introducido los browse servers y WINS.
Los principales clientes son de Microsoft y están incluidos en Windows for Workgroup 3.x, Windows 95 y Windows NT, los mismos se pueden ver cuando se usa el File Manager o el Explorer de Windows 95.
Los clientes son:
Las implementaciones del servidor están disponibles de muchas fuentes:
Dentro de este ítem hay que tener en cuenta dos significados:
|
|
