ACTIVIDADES 2 PARTE

ACTIVIDAD 3

Definir tiempos y escenarios para la instalacion del servidor.

Cómo instalar un servidor de impresión en Windows Server 2003 utilizando el Asistente para configurar su servidor:
1. Haga clic en Inicio, seleccione Herramientas administrativas y, a continuación, haga clic en Asistente para configurar su servidor.
2. Haga clic en Siguiente.
3. Haga clic en Siguiente.
4. En el cuadro Función del servidor, haga clic en Servidor de impresión y, a continuación, haga clic en Siguiente.
5. En la página "Impresoras y controladores de impresión", haga clic en los tipos de clientes de Windows que admitirá su servidor de impresión y, a continuación, haga clic en Siguiente.
6. Haga clic en Siguiente.
7. En la página "Asistente para agregar impresoras", haga clic en Siguiente.
8. Haga clic en Impresora local conectada a este equipo, desactive la casilla de verificación Detectar e instalar mi impresora Plug and Play automáticamente y, a continuación, haga clic en Siguiente.



9. Haga clic en el puerto de la impresora y, a continuación, haga clic en Siguiente.

10. Haga clic en la marca y el modelo de la impresora, o proporcione los controladores del disco del fabricante de la impresora y, después, haga clic en Siguiente.

NOTA:si le preguntan si desea mantener o no el controlador de impresión existente, manténgalo o reemplácelo. Si reemplaza el controlador, debe proporcionar el controlador del fabricante para esta impresora. Haga clic en Siguiente para continuar.

11. Acepte el nombre predeterminado de la impresora o proporcione un nombre diferente y haga clic en Siguiente.

12. Haga clic en Compartir como, escriba el nombre del recurso compartido y haga clic en Siguiente.

NOTA:este paso es opcional, ya que puede compartir la impresora más tarde.

13. Puede proporcionar la ubicación de la impresora y un comentario para que sea más fácil de encontrar. Haga clic en Siguiente para continuar.

14. Haga clic en la opción Imprimir página de prueba, haga clic en Siguiente y, después, haga clic en Finalizar para cerrar el Asistente para agregar impresoras. La impresora aparece en la carpeta Impresoras y faxes.

ACTIVIDADES

ACTIVIDAD 1
Formular 5 preguntas de la exposicion.
1.- ¿Qué es un servidor de impresión?
2.- ¿Cuáles son los tipos de interfaz que existen para los servidores de impresión?
3.- ¿Cuál es la función del servidor de impresión?
4.- ¿Cuál es la finalidad del servidor de impresión?
5.- ¿Que necesita un servidor de impresión para que funcione en una red?

ACTIVIDAD 2

Definir los recursos que se necesita para instalar el servidor asignado

Puerto Ethernet 10/100BASE-TX
Soporte SNMP y MIB-II (RFC 1213) para gestión independiente de plataforma
Tipo de intefaz USB o paralelo, 1 x red - Ethernet 10Base-T/100Base-TX - RJ-45
Protocolo de interconexion de datos Ethernet, Fast Ethernet
Protocolo de transporte TCP/IP, NetBEUI/NetBIOS
Sistema operativo requerido Microsoft Windows 98SE/2000/ME/XP/Vista
Dispositivo de alimentacion Adaptador de corriente - externa

RELOJ FÍSICO

La idea es proveer de un único bloque de tiempo para el sistema. Los procesos pueden usar la marca física del tiempo provista o leída de un reloj central para expresar algún orden en el conjunto de acciones que inician. La principal ventaja de este mecanismo es la simplicidad, aunque existen varios inconvenientes: el correcto registro del tiempo depende en la posibilidad de recibir correctamente y en todo momento, el tiempo actual desplegado por el reloj físico; los errores de transmisión se convierten en un impedimento para el orden deseado, el grado de exactitud depende de las constantes puestas en el sistemas.Los valores de tiempo asignados a los eventos no tienen porqué ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas es importante la hora real del reloj:

• Se precisan relojes físicos externos (más de uno).

Se deben sincronizar:

• Con los relojes del mundo real.
  
• Entre sí.

TIEMPO LÓGICO Y RELOJES LÓGICOS

TIEMPO LÓGICO Y RELOJES LÓGICOS

Los relojes lógicos son aquellos por los cuales están ordenados los sucesos de una forma única. Para poder usar en general el tiempo físico se debe sincronizar perfectamente bien los relojes a lo largo de un sistema distribuido para poder así obtener el orden de cualquier par arbitrario de sucesos que ocurran en el, pero es poco probable que esto ocurra por que no se puede sincronizar perfectamente los relojes a lo largo de un sistema distribuido. Se puede utilizar un esquema que similar a la casualidad física, que se aplica en los sistemas distribuidos, para controlar el orden de algunos sucesos que ocurren en diversos procesos. La cual esta basada en dos puntos sencillos y obvios.Cuando se envía un mensaje entre procesos, el suceso de enviar el mensaje ocurrió antes del de recepción del mismo.

Lamport llamo a la ordenación obtenida al generalizar estas dos relaciones la realización suceder antes. También se le conoce como la relación de orden casual o ordenación casual del mismo.La relación captura un flujo de información entre dos eventos.La información puede fluir de formas distintas de la de paso de mensajes.

SINCRONIZACION DE RELOJES

Sincronización de relojes

Un sistema distribuido debe permitir el apropiado uso de los recursos, debe encargarse de un buen desempeño y de la consistencia de los datos, además de mantener seguras todas estas operaciones La sincronización de procesos en los sistemas distribuidos resulta más compleja que en los centralizados, debido a que la información y el procesamiento se mantienen en diferentes nodos.

Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos cooperativos y de cómputo. Tales vistas pueden ser provistas por los mecanismos de sincronización.

El término sincronización se define como la forma de forzar un orden parcial o total en cualquier conjunto de eventos, y es usado para hacer referencia a tres problemas distintos pero relacionados entre sí:

1.La sincronización entre el emisor y el receptor.

2.La especificación y control de la actividad común entre procesos cooperativos.

3.La serialización de accesos concurrentes a objetos compartidos por múltiples procesos.Haciendo referencia a los métodos utilizados en un sistema centralizado, el cual hace uso de semáforos y monitores; en un sistema distribuido se utilizan algoritmos distribuidos para sincronizar el trabajo común entre los procesos y estos algoritmos.

TOLERANCIA A FALLOS

TOLERANCIA A FALLOS

Es la propiedad de ciertos ordenadores de funcionar aún cuando se haya producido una avería en alguno de sus componentes. Se obtiene a base de duplicidad de elementos y otras técnicas. Es algo propio de sistemas que precisan de una alta disponibilidad en función de la importancia estratégica de las tareas que realizan, o del servicio que han de dar a un gran número de usuarios.

Es la propiedad que permite a un sistema continuar operando adecuadamente en caso de una falla en alguno de sus componentes. La tolerancia de fallas es muy importante en aquellos sistemas que deben funcionar todo el tiempo. Ante una falla, otro componente o un procedimiento especial de respaldo pueden tomar el control para subsanar o amortiguar los efectos del fallo. Una forma de lograr tolerancia de fallas, es duplicar cada componente del sistema.

La tolerancia a fallos es un área de conocimiento que surge inicialmente en las industrias críticas (como la nuclear, la petroquímica, la espacial, la aeronáutica o la del transporte) con el fin de proporcionar soluciones viables para garantizar el correcto funcionamiento de los sistemas informáticos incluso en entornos de ejecución hostiles. Actualmente, el ámbito de aplicación de las técnicas de tolerancia a fallos se ha extendido a todos aquellos contextos en los que el funcionamiento incorrecto de un computador, o de una de sus partes, puede comportar importantes pérdidas humanas y/o económicas.

De hecho, cada vez son más los usuarios que, en todo tipo de contextos y para todo tipo de sistemas, demandan productos que hagan lo que tienen que hacer de manera segura y fiable, es decir, que exigen funcionalidad, pero sin renunciar a aspectos cada vez más importantes como la fiabilidad, la seguridad, la disponibilidad o la facilidad de mantenimiento de sus sistemas. De hecho ¿quién está hoy en día dispuesto a adquirir un equipo que no posea las características que acabamos de mencionar?

RCP

RPC

El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.

Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.

Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.

Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden ser SOAP o XML-RPC.
XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes.

Es un protocolo muy simple ya que sólo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión. La simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tiene una documentación extensa y requiere considerable soporte de software para su uso.

Fue creado por Dave Winer de la empresa UserLand Software en asociación con Microsoft en el año 1998. Al considerar Microsoft que era muy simple decidió añadirle funcionalidades, tras las cuales, después de varias etapas de desarrollo, el estándar dejó de ser sencillo y se convirtió en lo que es actualmente conocido como SOAP. Una diferencia fundamental es que en los procedimientos en SOAP los parámetros tienen nombre y no interesan su orden, no siendo así en XML-RPC.