SISTEMAS OPERATIVOS UNIX

Introducción al sistema operativo UNIX.

 

UNIX es un sistema operativo multitarea y multiusuario, lo cual significa que puede ejecutar varios programas simultáneamente, y que puede gestionar a varios usuarios simultáneamente. Se desarrolló en los laboratorios Bell (por Kernighan & Thompson), y aunque al principio se diseñó para el PDP-11, una máquina de Digital, ahora se ejecuta en gran cantidad de plataformas con muchos tipos de microprocesadores diferentes, haciéndolo un sistema multiplataforma, y provocando por tanto que un programa en código máquina ejecutable en una plataforma en UNIX no tenga por qué ser ejecutable en otra. Sin embargo, todos los UNIX son compatibles a dos niveles.

 

Comandos del sistema operativo, y grupos de ellos, es decir, scripts. Programas en C en código fuente, siempre que se utilicen las librerías estándar. Una librería es un conjunto de funciones que el usuario puede utilizar, que vienen aparte del compilador.

 

Esta multiplicidad de plataformas hace que UNIX venga en diferentes sabores, casi uno por cada fabricante y para cada tipo de máquina. Además, hay dos grupos (bueno, quizás 3) de desarrollo diferentes:

 

v    System V: liderado por AT&T, y acompañado por Sun y otra serie de fabricantes, va por la versión 4.

v    BSD, el más utilizado en las universidades.

 

Aparte, hay una serie de intentos de llegar a un UNIX totalmente estándar, pero al haber varios, estos intentos son en vano. En concreto, son los siguientes:

v    UNIX International, de AT&T y Sun. Open Software Foundation, que ha hecho ya un sistema operativo, OSF/1, y un IGU (interfaz gráfica de usuario), OSF Motif, liderado por IBM y su peña.

Hay otros intentos independientes, como GNU (Gnu's not UNIX), de hacer un sistema operativo gratuito e independiente del fabricante, y POSIX, un intento estándar del IEEE. Por supuesto, el más celebre y utilizado hoy en día es el Linux, del cual acaba de salir la versión 2.2. En realidad, casi todos los UNIX ofrecen compatibilidad POSIX, e incluso algunos no- UNIX, como el Windows NT, sobre todo si quieren ganar contratos del gobierno americano, que exige compatibilidad POSIX (especificación GOSIP) para los sistemas operativos instalados en ordenadores gubernamentales. Y, por supuesto, el sistema operativo gratuito de más éxito en la actualidad, LINUX, creado inicialmente por Linus Torvalds con ayuda de mucha otra gente en la Internet. Pero no es único sistema operativo unixoide gratuito: también está MachTen (para el Macintosh) y NetBSD.

En fin, el estándar de facto es SunOs, o Solaris 2.5, de las estaciones de trabajo Sun y compatibles, ya que es el utilizado por la mayoría de los ordenadores instalados.

UNIX es un sistema operativo de red y tiene algunas características de sistema distribuido, ya que existe un nombre único para todos los ficheros disponibles en la red, y que es independiente de la máquina, o más específicamente, en ese nombre no se incluye el nombre de la máquina en el que el fichero está almacenado. Esto se denomina transparencia de localización, y se logra, por ejemplo, con el NFS de Sun.

 

Hay cienes de interfaces para usuario basados en UNIX, pero la mayoría utilizan como rutinas básicas para dibujo y gestión de ventanas X-Windows, también llamado X11, por ser la última versión. X-Windows no es la interfaz para el usuario, pero son utilizadas por diversas interfaces para el usuario como conjunto básico de primitivas gráficas o sistema de imaginería. Es, además, un sistema de presentación de gráficos en una red.

Algunas versiones: AIX de IBM, A/UX de Apple, HP-UX de Hewlett Packard, DG/UX de Data General, SunOS de Sun, IRIX para las estaciones de trabajo Silicon Graphics; y, en general, casi todo entorno operativo que lleve una X por algún lado.

PROCESOS.

Un programa ejecutándose es para UNIX un proceso; cada programa recibe del sistema operativo un número de proceso o pid. Cada proceso tiene una determinada prioridad de ejecución, y en función de la misma, recibirá la atención de la CPU durante más o menos tiempo.

Cada usuario puede controlar sus propios procesos, pero no los de los demás. Solo el superusuario puede controlar todos, y de hecho lo hace muchas veces. Los procesos se controlan enviándoles señales, que les indican por ejemplo, que deben terminar de ejecutarse, pero también que deben rearrancar o que que paren para seguir luego más adelante.

Algunas órdenes relacionadas con los procesos son las siguientes:

v    lista de los procesos propios, en la consola actual: (kal-el) ~> ps

   PID TTY       TIME COMMAND

  1270 ttyq1     0:00 ps

   553 ttyq1     0:01 tcsh

indica el numero de proceso, en que terminal o teletype se está conectado, el tiempo que se ha estado ejecutando y el nombre del comando. En Solaris aparecería de la siguiente forma: turing% ps

PID TTY      TIME COMD

 13122 pts/44   0:00 ps

 11115 pts/44   0:02 tcsh

 

1.    kill <señal> <número de proceso hace que un proceso se deje de ejecutar; por ejemplo, puede usarse si se hay un proceso “colgado”. En realidad, kill manda una señal al proceso, a la que ese proceso, normalmente, debe de responder. Si el proceso no responde, hay que mandarle una señal más fuerte. Por defecto, kill envía la señal SIGTERM, o “terminar”, pero si el proceso está especialmente colgado, hay que mandarle la SIGKILL, “asesinar”, escribiendo kill -KILL <pid> o kill -9 <pid>: a cada señal le corresponde un código numérico, y a veces una combinación de teclas. Otras señales tienen equivalencias también en pulsaciones de tecla, como SIGSTOP, “parar”, que equivale a pulsar Ctrl-Z mientras un programa se está ejecutando, para pararlo; el programa puede continuar ejecutándose mandándole (curiosamente también con kill la señal SIGCONT (“continuar”). Otras señales, como SIGSEGV, o “violación de segmentación”, son enviadas al programa por el sistema operativo cuando aquel trata de escribir en una posición de memoria que no debe. Por otro lado, en algunos sistemas existe la orden killall, que hace lo mismo usando nombres de procesos, en vez de PIDs. En otros sistemas diferentes, killall manda una señal a todos los procesos.

2.    nice <orden>, renice <numero de proceso> hace que una orden se        ejecute con baja prioridad; y renice altera la prioridad de un proceso una vez que ya se está ejecutando.

Un proceso, además, se puede ejecutar en background o segundo plano sin que bloquee un terminal, incluyendo el símbolo de and, &, o ampersand, al final. Control-Z pasa al background un proceso que se este ejecutando en primer plano; también se puede hacer con bg <número de proceso>; fg <número de proceso>, sin embargo, lo trae al primer plano.

Un programa ejecutándose es para UNIX un proceso; cada programa recibe del sistema operativo un número de proceso o pid. Cada proceso tiene una determinada prioridad de ejecución, y en función de la misma, recibirá la atención de la CPU durante más o menos tiempo.

Cada usuario puede controlar sus propios procesos, pero no los de los demás. Solo el superusuario puede controlar todos, y de hecho lo hace muchas veces. Los procesos se controlan enviándoles señales, que les indican por ejemplo, que deben terminar de ejecutarse, pero también que deben rearrancar o que que paren para seguir luego más adelante.

Algunas órdenes relacionadas con los procesos son las siguientes:

v    lista de los procesos propios, en la consola actual: (kal-el) ~> ps

   PID TTY       TIME COMMAND

  1270 ttyq1     0:00 ps

   553 ttyq1     0:01 tcsh

indica el numero de proceso, en que terminal o teletype se está conectado, el tiempo que se ha estado ejecutando y el nombre del comando. En Solaris aparecería de la siguiente forma: turing% ps

PID TTY      TIME COMD

13122 pts/44   0:00 ps

11115 pts/44   0:02 tcsh

 

1.    kill <señal> <número de proceso hace que un proceso se deje de ejecutar; por ejemplo, puede usarse si se hay un proceso “colgado”. En realidad, kill manda una señal al proceso, a la que ese proceso, normalmente, debe de responder. Si el proceso no responde, hay que mandarle una señal más fuerte. Por defecto, kill envía la señal SIGTERM, o “terminar”, pero si el proceso está especialmente colgado, hay que mandarle la SIGKILL, “asesinar”, escribiendo kill -KILL <pid> o kill -9 <pid>: a cada señal le corresponde un código numérico, y a veces una combinación de teclas. Otras señales tienen equivalencias también en pulsaciones de tecla, como SIGSTOP, “parar”, que equivale a pulsar Ctrl-Z mientras un programa se está ejecutando, para pararlo; el programa puede continuar ejecutándose mandándole (curiosamente también con kill la señal).

COMUNICACIONES.

 

 

       En los años 70, Brian Kernighan y Ken Thompson,  empleados de AT&T, decidieron escribir un sistema operativo nuevo para una maquina digital muy conocida en ese entonces PDP-7. Dicho sistema operativo debió ser multiusuario y multitarea. Llamaron a dicho sistema operativo UNIX que, aunque parezca raro, no son las iniciales de nada, sino que es un derivado de un nombre del sistema operativo MINIX, el cual evoluciona.

      

La primera versión de UNIX fue escrito en Assembler, pero en posteriores versiones se utilizó un lenguaje de alto nivel, él “C”. La idea de utilizar un lenguaje de alto nivel fue asegurar  que el sistema sea portable, es decir, que pudiera correrse en otras computadoras. En este sentido, UNIX fue el primer sistema operativo escrito con este objeto en mente.

      

Un sistema UNIX posee una estructura de capas. En el centro encontramos el hardware y redondeándolo el corazón o “kernel” del sistema. La función del kernel es la administración del hardware (memoria, periféricos), y de los procesos. Por afuera de los mismos encontramos los “shells” o interfaces a de comando. Los shells son programables mediante scripts, como los archivos BAT del DOS, pero en un lenguaje mucho mas poderoso. Por afuera de los shell encontramos los comandos y las aplicaciones. Estos pueden comunicarse con el shell o con el kernel directamente. En general, las aplicaciones no interactuan con el hardware como suele suceder con el DOS, pues de esa manera son portables mas fácilmente entre distintas plataformas, metas muy buscada en el mundo UNIX y no tanto en el mundo DOS.

      

Entre las ventajas que posee encontramos:

C     Gran configurabilidad. Muchos parámetros del sistema operativo pueden ser modificados. De hecho si se licencia el código fuente, puede modificarse el kernel.

C     Diversidad de plataforma.

C     A partir del System V Release 4 existen una cierta estandarización.

 

Entre sus fallas se detectaron:

C     A pesar de los esfuerzos de todos los desarroladores, aun existen diferencias entre los distintos UNIX.

C     Es un sistema operativo muy poco amigable con el usuario. Así, puede hablarse de un “temor de UNIX” entre la gente de sistemas que no lo conocen. Se han desarrollado interfaces gráficas que facilitan en gran parte su administración y manejo.

 

UNIX fue diseñado desde el principio para facilitar al máximo  las comunicaciones, tanto de los usuarios del sistema como entre los distintos operadores (computadoras); no solo entre ordenadores con UNIX, sino también entre ordenadores con UNIX y a ordenadores con otros sistemas operativos.

 

 

SISTEMAS DISTRIBUIDOS.

 

 

Una meta de largo alcance en las comunicaciones entre las computadoras es proveer conectividad mundial entre computadoras y usuarios. Para se aceptable el amplio rango de intereses involucrados, las técnicas de comunicación deben ser decididas por consenso; para tal fin a sido desarrollado el estándar OSI (Open System Interconnection). Esta es una arquitectura de red de especial importancia, por que ha sido aceptada en el ámbito mundial.

 

 

ARQUITECTURA OSI.

 

       El modelo de referencia OSI es una descomposición arbitraria de funciones de comunicación de computaras en siete niveles de abstracción denominados capas. Cada capa tiene ciertas funciones conceptuales asociadas con ella, las cuales se implementan de varias formas por medios de diferentes servicios y protocolos.

 

Existe una amplia variedad de estándares que no han tenido acepción mundial. Algunos de estos son  IBM’S System Network Architecture (y a su implementación DECnet), y el conjunto de protocolos del Departamento de  Defensa de EE.UU. (DoD).

 

       Los protocolos DoD son ampliamente usados en los Estados Unidos especialmente en la comunidad de sistemas UNIX.

 

 

 

CAPAS

 

 

       Las capas individuales de una arquitectura de red se realizan con definiciones de servicios y protocolos. En termino de la arquitectura OSI, la implementación de la capa n es una entidad n. La capa llamada sobre la entidad n es una entidad (n+1) y es el usuario de servicio n. La capa inferior a la capa n desde la cual la entidad n requiere servicios, es la entidad (n-1). Un servicio n, de acuerdo a la modelo referencia OSI, es una capacidad de la capa n y las capas inferiores a ella, la cual es provista por la (n+1) entidades en él limite entre la  capa n y la capa (n+1).

 

       La implementación de interfaces de servicios (por ejemplo, las reglas mediante las cuales el usuario n requiere (n-1) servicios dentro del sistema abierto), no esta estandarizado por OSI. Las interfaces de servicios son realizadas típicamente como llamadas al sistema operativo. La sintaxis y la semántica de las interfaces de protocolos están rígidamente estandarizadas; estas definen las reglas usadas entre las comunicaciones de n entidades.

        

 

UNIDADES DE DATOS DE PROTOCOLOS Y DE DATOS DE SERVICIO.

 

      

Varios tipos de datos conceptuales se han involucrado en la realización de servicios OSI. El principio básico de movimiento de datos en OSI es que n entidades se comuniquen con cualquier otra usando una (n-1) conexión entre (n-1) entidades. Las n entidades  intercambian n información de control de protocolo para manejar sus operaciones cooperativas, e intercambian n datos de usuarios. La combinación de información de control de protocolo y datos de usuario es una unidad de datos de protocolo (PDU); la semántica y la sintaxis de la PDU están totalmente especificadas en los estándares de protocolo OSI. Las PDU pueden clasificarse por el nombre de capas (ejemplo: Unidad de Datos de Protocolos de Red o NPDU).

 

       Cuando una entidad n envía n datos de interfaces a una entidad (n-1), estos datos forman una (n-1) Unidad de Datos de Servicios (SDU). Las SDU se clasifican usualmente por el servicio que esta siendo usada, tal como Unidad de Datos de Servicios de Transporte (TSDU) para el servicio de transporte.

 

       Cuando se usa una entidad (n-1) para enviar n SDUs a través de la red, una entidad (n-1) construye normalmente una PDU en respuesta de servicio requerido colocando sus propios cabezales  y pistas de protocolos alrededor  de una representación de la SDU n. La entidad (n-1) envía entonces las SDU n encapsuladas como una SDU (n-2) a la capa (n-2) debajo de la entidad (n-1). La recepción es a la inversa: cada capa saca su propia información de control de protocolo desde las unidades de datos, y coloca el contenido de los campos de datos de la PDU n en la entidad (n+1).

 

       No se necesita una correspondencia uno a uno entre n SDUs y la (n-1) PDUs usadas para transferirlas, o  entre n conexiones y las (n-1) conexiones sobre las cuales fluyen las PDUs. Una conexión (n-1) puede soportar mas de una conexión n.

 

 

 

LA CAPA DE APLICACIÓN.

 

 

       La capa de aplicación OSI  no incluye aplicaciones en el sentido convencional tales como planilla de pago, inventario, etc. Mas bien, la capa de aplicación es una interfaces para distribuir funciones del sistema operativo, tales como la capacidad para abrir un fichero o llamar aun procedimiento remoto. Esta inteface esta descripta abstractamente, la interface especifica entre un sistema operativo real y una implementación real de la capa de aplicación no esta sujeta a la estandarización OSI, ya que estas interfaces están estandarizadas por diversos grupos tales como X/OPEN, the Open Software Foundation, UNIX international, y otros.

 

       La capa de aplicación tienen componente que proveen servicios a los  elementos de servicios de aplicación especifica (SASE) de software que no es de OSI, y otros servicios, los cuales proveen servicios dentro de la capa de aplicación (por ejemplo, a SASE). Los SASEs más comunes son  Sistemas de Manejos de Mensajes (MHS) y Transferencia; Acceso y Manejo de Ficheros (FTAM). Otros SASEs incluyen Protocolo de Terminal Virtual (VTP), Servicios de Mensajes Confeccionados (MMS), Servicios de  Directorios (DS), y Proceso de Transacción (TP).  El Manejo de Red es un SASE especial.

 

       MHS provee mecanismo para la transferencia de correo electrónico entre computadoras y entre redes de trabajo; éste no establece la interface humana  para los sistemas de correos.

 

 

PROTOCOLO DE TRANSMISION / PROTOCOLO DE INTERNET.

 

      

El departamento de Defensa de los EE.UU.  Ha desarrollado un juego de protocolos ampliamente aceptado, parte del cual es el protocolo de control de transmisión (TCP) y el protocolo de Internet  (IP), o simplemente TCP/IP.

 

       Otros protocolos en este juego incluyen el protocolo de transferencia de correo simple (SMTP) y protocolo de transferencia de ficheros (FTP). En el juego de protocolo DoD, los protocolos de “aplicación” tales como SMTP y FTP incluyen la funcionalidad de las capas cinco a siete de OSI. Los servicios SMTP son considerados un subconjunto de FTAM. TCP provee servicios generalmente comparables al transporte de OSI. Un desarrollo considerable ha sido realizado con el ampliamente distribuido en torno de desarrollo ISO (isode), el cual provee capas superiores de OSI al principio de TCP/IP; ISODE está migrando a los sistemas Berkeley`s UNIX.

 

       El modelo arquitectónico para los protocolos DoD está informalmente descripto  por Padlipsky, y está dado por cuatro capas: aplicación/proceso, host-host, red de trabajo y procesador de sub-red de comunicaciones (CSNP) para CSNP. La capa de aplicación/proceso combina la funcionalidad de las tres capas superiores de OSI. Los protocolos host-host corresponden aproximadamente a la capa de transporte OSI, los protocolos de red de trabajo corresponden a la capa de red OSI, y los protocolos CSNP-CSNP son específicos para tipos  individuales de redes de transmisión.

 

       TCP/IP es importante para estudiante de sistema operativo  por que es  ampliamente usado. Su éxito está mayormente  limitado a los EE.UU.; No ha sido aceptado como un estándar en el ámbito mundial. La migración de redes basadas en OSI es un hecho durante los noventas.

 

 

 

COMUNICACIÓN ENTRE PROCESOS.

 

      

Muchos recursos separados son provistos para permitir a procesos concurrentes comunicarse con otros. Los conductores son caminos unidireccionales sobre los cuales los procesos pueden enviar corrientes de datos a otros procesos. Los Conductores Etiquetados (del UNIX System V) son caminos permanentes. Los Mensajes (también de UNIX System V) transfieren elementos de datos pequeños.

 

       SunOs  incluye el mecanismo de socket a partir de BSD 4.2. Los sokets son puntos finales de caminos  de comunicación de dos vías.  Ellos son especialmente usados para implementar protocolos de red. Un proceso cliente en una maquina en la red  comienza la comunicación desde u socket; un proceso servidor en otra máquina escucha al socket para recibir la comunicación.

 

       SunOs provee capacidad de memoria compartida del Sistema V. Los procesos comparten una porción de memoria; cuando un proceso completa la escritura a esta área de memoria, otro proceso puede leer los datos. SunOs provee también semáforos del UNIX  System V para controlar el acceso a recursos compartidos. Un semáforo se usa  para bloquear una prioridad de recurso compartido para su uso; el proceso usa el recurso y luego usa una operación  de semáforo para liberar el recurso.

 

        

 

CONDUCTOS Y FILTROS.

 

      

Un conducto es un camino de comunicación, consiste en una cola FIFO de bytes, entre dos procesos; permite que la salida de un proceso sea la entrada de otro proceso. La información escrita en un extremo del conducto  puede ser leída desde el conducto en el otro extremo. La sincronización, planificación  y el buffer son manejados automáticamente por el sistema. Un usuario puede crear una línea de conductos conectando diversos procesos a través de conductos de modo lineal. El usuario especifica una línea de conductos al shell mediante una serie de nombres de ficheros separados por barras verticales. La salida estándar de un fichero ejecutable nombrado a la izquierda de una barra es la entrada estándar del fichero ubicado a la derecha de la barra.

 

El llamado al conductor retorna un descriptor para el extremo de  escritura del conducto y otro descriptor  para el extremo de lectura. El llamado al sistema de escritura especifica al descriptor, el área de datos contiene los bytes que serán escritos, y el número de bytes correspondiente. Si ocurre un error, retorna el valor -1.

 

       La escritura termina con la llamada al sistema de cierre. La llamada al sistema de lectura retorna un  valor 0 cuando el conductor está vacío  y no hay escritores.

 

Debido a que los procesos asincrónicos pueden leer y escribir  en el conducto, el sistema operativo se realiza las operaciones concurrentes en el conducto. Una escritura a un conducto lleno bloquea al escritor hasta que haya espacio disponible. Una lectura desde un conductor vacío bloquea al lector hasta que los datos estén en el  conducto.

 

       Los conductos son entidades locales; un proceso que desea leer o escribir  en un conducto, debe poseer el  descriptor de conductos. Un proceso que crea un conducto puede utilizarlo, y un proceso hijo de éste también puede utilizarlo. Los procesos no relacionados necesitan, de cualquier modo, comunicarse. Para resolver estos problemas, UNIX System III introduce conductos etiquetados, UNIX System V introducen colas de mensaje,  y Berkeley`s BSD System introduce socket.

 

       Un filtro es un programa que procesa una corriente simple de entrada para generar una corriente simple de salida. Los filtros y conductos pueden usarse para generar múltiples  salidas interesantes.

 

Algunos ejemplos de filtros UNIX son tr (carácter de traducción), cut (copia solo la porción de una línea), pg (visualiza una página de salida a la vez), tail (escribe las últimas diez líneas de un fichero), dd (realiza una copia exacta de un disquete).

SISTEMAS UNIX DISTRIBUIDOS.

       Los sistemas UNIX han desarrollado una posición  especial de predominancia en los sistemaas distribuidos, especialmente por que ellos necesitan interconectar equipos de muchos fabricantes que utilizan diferentes arquitectura. Teniendo un sistema operativo común, así como también son comunes los tipos de protocolos de comunicación,  facilita la tarea de los sistemas distribuidos desarrollados.

       A continuación se discutirán las cuatros mayores contribuciones que han hecho  que UNIX incremente su viabilidad como una base para los sistemas distribuidos.

 

BERKELEY`S SOCKETS.

       El sistema Berkeley`s 4.2 BSD introduce Socket para establecer las comunicaciones entre procesos en un sistema  distribuido. Los Sockets también establecen comunicaciones entre procesos no relacionados en la misma máquina.

       En UNIX 4.3 BSD, el Socket es la unidad fundamental para comunicaciones. Los Sockets son puntos finales de comunicación. Pueden ser vinculados con nombres. Cada socket está asociado con uno o más procesos. UNIX 4.3 BSD soporta tres dominios de comunicación, y los sockets normalmente se comunican con otros sockets en el mismo dominio. Los tipos de dominio de comunicación son:

v    El dominio de sistema UNIX  (para comunicaciones  “on- system”).

v    El dominio Internet (para comunicación usando protocolos estándar DARPA).

DARPA es la agencia de Proyectos de Investigación Avanzados de Defensa del Departamento de Defensa de los EE.UU.

v    El dominio NS para comunicaciones que usan los protocolos de comunicación estándar XEROX.

 

 

AT&T`s STREAMS.

 

 

El mecanismo AT&T`s Streams provee un número de características para transmisiones de alta velocidad. Streams facilita  la implementación de protocolos de red en capas tales como OSI, SNA, TCP/IP y XNS.

       Un Streams es un camino bidireccional entre un proceso en el espacio de usuario y un manejador de dispositivo en el espacio kernel. Los módulos de procesos pueden ser configurados dinámicamente  en un stream de manera tal que los programas pueden agregar servicios a los naturalmente previstos por los dispositivos.

       Con manejadores de dispositivos, las llamadas al sistema  son conmutadas  a los manejadores; con streams, las llamadas al sistema crean mensajes para comunicarse con los manejadores. Un stream asocia un par de colas (una para lectura y otra para escritura) con el usuario y otro par con el dispositivo. Las colas son enlazadas para formar un stream entre el manejador de dispositivo y el usuario.  Para cada cola hay cuatros rutinas:

v    Open es llamada cuando el dispositivo es abierto.

v    Close es llamada cuando el dispositivo está cerrado.

v    Put coloca datos en la cola.

v    Service sirve la cola y los datos de salida en un dispositivo o en la siguiente cola.

 

NETWORK FILE SYSTEM (NFS).

 

           

NFS le da a los sistemas de archivos remotos la apariencia de estar montados  localmente, haciendo la operación de la red transparente a la ubicación de los archivos.

       La computadora de una red es referida como nodos, cada uno con un nombre único. Un nodo puede ser un servidor, un cliente,  o  ambos.

       Un servidor provee servicios a los procesos o usuarios de uno o más clientes. Un nodo distribuye las llamadas al sistema y/o los comandos para conveniencia de un servido o un cliente.

       NFS y otros servicios de red de Sun se basan en los estándares Llamado a procedimiento remoto (RPC) y Representación de Datos Externos (XDR) desarrollados  Sun Microsystem. RPC permite que los programas que se ejecutan en diferentes sistemas operativos se llamen entre sí y reciban valores de retorno. El RPC del cliente traduce cada llamada a un formulario estándar y lo transmite al servidor. El RPC del servidor acepta  el llamado, lo traduce al formato del servidor, e inicia el procedimiento llamado, transfiriendo los parámetros apropiados. XDR es un formato estándar de representar datos transferidos  entre diferentes máquinas.

      

 

AT&T REMOT FILE SYSTEM (RFS).

El sistema de archivos remotos fue desarrollado por AT&T para facilitar la computación distribuida con el UNIX System V. Es un protocolo independiente; a medida que protocolos de red nuevos comienzan a emerger (tal como OSI), pueden ser fácilmente instalados en sistemas basados en RFS.

       Los requerimientos son realizados por el cliente, pasando un mensaje al servidor, este último realiza el requerimiento y devuelve un mensaje en respuesta. RFS usa un modelo  de montado remoto; los nodos individuales comparten en la red sólo  aquellos archivos y directorios que desean; otros archivos permanecen como privados.

       Los diseñadores de RFS optaron por usar servidores de estado completo antes que los accesos a servidores de estado parcial usados en NFS. Una debilidad de los accesos de estados parcial es que limitan las semánticas de las operaciones remotas. AT&T optó por usar acceso a servidores de estado completos debido a que desea que NFS soporte todas las semánticas del sistema UNIX, inclusive las capacidades de estado completo tales como bloqueo de registros y archivos, y varias operaciones de dispositivos periféricos.

 

 

CORREO ELECTRONICO Y COMUNICACIONES EN UNIX.

 

COMUNICACIONES ENTRE USUARIOS DEL MISNO SISTEMA.

 

 

       Existen dos medios principales de comunicación entre los usuarios de un mismo sistema UNIX: estos son los ordenadores WRITE y MAIL.

       La orden write fue diseñada para un diálogo inmediato entre dos usuarios de UNIX. La orden mail sirve para comunicaciones en las cuales en contenido de las mismas será  almacenado en un archivo.

       UNIX ofrece también un servicio de agenda de uso transparente mediante la orden CALENDAR.

 

 

DIALOGO ENTRE USUARIOS CON WRITE.

 

 

         Para establecer esta forma de comunicación el usuario debe asegurarse de que el receptor esté presente en el sistema.  Esto se logra ejecutando la orden WHO. Esta orden nos mostrará el nombre del usuario conectado, el terminal al que está conectado, la fecha y la hora del comienzo de la sesión.

       Los mensajes enviados por write aparecen súbitamente en la pantalla del usuario receptor. Esto es un inconveniente porque el mensaje puede aparecer en medio de la creación de un texto importante. Para solucionar esto el usuario puede denegar el permiso de acceso a la orden write mediante:

              $ mesg n: Deniega el permiso de acceso a la orden write.

 

       De esta manera, cualquier usuario que desee comunicarse con ese usuario recibirá el mensaje “Permission denied”.

       La orden $ mesg y: otorga nuevamente permiso de acceso a la terminal para orden write.

 

MENSAJE A TODOS LOS USUARIOS CON WALL.

 

           

Esta orden está almacenada en el directorio /etc/wall, el cual contiene varias ordenes que son usadas especialmente por el superusuario. Es conveniente que este directorio esté incluido en la variable PATH  del archivo profile de todos los usuarios que deseen utilizarlas.

 

 

 

CONFIGURANDO EL CORREO ELECTRONICO

 

Para mandar y recibir correo electrónico, hay programas específicos, tales como el Eudora, el P-mail o el Pine; pero en muchos casos es mejor utilizar el cliente de correo incluido en el navegador de Internet, tal como el Netscape o el Explorer. En el caso del netscape, para configurarlo hay que seguir los siguientes pasos:

v    Depende de las versiones, pero en general hay que ir al menú Edit<Imagen: $\rightarrow$>Preferences.

v    Ahí hay que escoger Mail & Groups, y desplegar el menú pulsando sobre el triángulo que tiene la punta hacia la derecha.

v    Se escoge el submenu Mail Server, para definir el ordenador desde el cual se va a recoger el correo (Turing en el caso de la ETSII.

v    Hay que definir quien es uno (username), que ordenador va a recibir el correo saliente (outgoing) y de donde se recoge el correo entrante (incoming). El nombre de usuario será el habitual, el que nos haya asignado el administrador, y en el caso de la ETSII tanto el servidor saliente como el entrante son turing.ugr.es.

v    Una vez echo esto, se pueden definir también los grupos de noticias o newgroup. Se hará lo mismo en el submenú Groups server. En Granada, el servidor es news.cica.es.

 

CORREO ELECTRONICO CON MAIL.

 

       UNIX mantiene una oficina de correos para todos los usuarios del sistema en el directorio /usr/spool/mail.

 

 

 

COMUNICACIONES ENTRE ORDENADORES.

 

      

UNIX fue diseñado en principio como un S.O. que hace relativamente fácil la comunicación entre ordenadores, no sólo entre ordenadores con UNIX sino también entre ordenadores con UNIX y ordenadores con otros S.O.

       Aunque las comunicaciones entre ordenadores separados por grandes distancias a través de líneas telefónicas no son un concepto nuevo, los que utilizan UNIX poseen la ventaja de que los programas de utilidad necesarios para establecer las comunicaciones forman parte del S.O. y son directamente accesibles al usuario final.

 

 

 

CONCLUSION.

 

       UNIX es un sistema operativo muy versátil y hoy en día despliega sus potencialidades en  entornos muy disímiles. Entre otros se encuentran los siguientes:

v    Mainframes y microcomputadoras de distintos tamaños.

v    Estaciones de trabajos.

v    Supercomputadors.

v    Sistemas tolerantes a fallas (en este caso el sistema corre un derivado de UNIX que soporta la operación de este tipo de máquinas).

v    Sistema de control en tiempo real (en este caso, UNIX fue modificado para dar soporte a operaciones en tiempo real, es decir, ejecutables en un lapso predecible). Un sistema  comercial UNIX  de tiempo real es el QNX.

v    LINUX es la variante más popular que posee varias característica que lo hacen único, es la versión de UNIX para PCs. Fue escrito por el finlandés Linus Thorvald, por ese motivo se distribuye gratuitamente.

 

 

BIBLIOGRAFIA:

 

 

v    Compumagazine Nº 99           Octubre 96.

v    Operating Systems,  M. Deitel, Segunda Edición, 1990.

v    El Sistema Operativo UNIX (Xenix), José Canosa, 1998.

v    Administración UNIX, Jean-Luc Montagnier 1996.

 

      

 

                     

   Anterior          Índice          Siguiente

Para mayor información, seleccione una opción:

Número de visitas efectuadas desde el 17/12/2001: 
 
Estadísticas diarias desde el 10/07/2002:    

Número de visitantes actuales disponible desde el 14/07/2002:

 

AddFreeStats.com Free Web Stats in real-time !  

 

 

 

Autor: lrmdavid@exa.unne.edu.ar

Ó FACENA - http://exa.unne.edu.ar

Servicios WEB: webmaster@exa.unne.edu.ar