Cliente servidor
Upcoming SlideShare
Loading in...5
×
 

Cliente servidor

on

  • 4,708 views

calzada meza

calzada meza

Statistics

Views

Total Views
4,708
Views on SlideShare
4,708
Embed Views
0

Actions

Likes
4
Downloads
172
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cliente servidor Cliente servidor Presentation Transcript

  • CLIENTE SERVIDOR
    Alumno: Calzada meza, José Antonio
    Tema: Cliente Servidor
  • Tema I:
    EL PARADIGMA CLIENTE SERVIDOR
  • EL PARADIGMA CLIENTE SERVIDOR
    En la práctica el esquema de programación mas utilizado para la implementación de aplicaciones distribuidas es el paradigma cliente - servidor. La motivación fundamental para el empleo del paradigma cliente - servidor surge del problema del rendezvous.
    Para entender dicho problema, imaginemos un técnico de computadoras que inicia la ejecución de dos programas en máquinas distintas y que tiene la intención de que dichos programas puedan comunicar entre sí.
    Una vez iniciado el primer programa este envía un mensaje a su contertulio. La conexión con la maquina a la cual va dirigido el mensaje se puede establecer en un intervalo de unos pocos milisegundos (recordar que las computadoras funcionan a velocidades muchos ordenes de magnitud por encima de los humanos), por lo que el proceso recién lanzado determina que su contertulio todavía no existe, con lo cual emite un mensaje de error y finaliza su ejecución.
    View slide
  • El paradigma cliente-servidor como abstracción
    El modelo de paso de mensajes
    No especifica cómo se sincronizan los procesos
    No especifica cuantos tipos de procesos comunican
    No especifica el protocolo (diálogo) a seguir entre los procesos
    El paradigma cliente-servidor es una abstracción del modelo de paso de mensajes
    Especifica cómo se sincronizan los procesos: el servidor espera de forma pasiva la llegada de peticiones de clientes
    Especifica que hay dos tipos de procesos y sus roles: servidores y clientes
    Especifica el modelo de diálogo basado en petición-respuesta
    Restringirnos al modelo cliente-servidor, limita lo que podemos hacer con una aplicación distribuida, pero abstrae algunos de los problemas asociados al IPC
    Al desarrollar con APIs cliente-servidor (i.e.servlets) se percibe esa abstracción
    View slide
  • El paradigma cliente-servidor como arquitectura software
    Definición de arquitectura de un sistema software “La arquitectura comprende la enumeración de los componentes software especificando sus interfaces y la relación que estos guardan entre sí”
    Un patrón arquitectural es una plantilla o descripción que puede aplicarse al diseño de arquitecturas de sistemas que tienen una problemática similar
    El modelo cliente servidor es un patrón arquitectural de software distribuido que define dos tipos de componentes y un modelo de interacción basado en un diálogo
    petición-respuesta
    Este patrón arquitectural puede aplicarse al diseño de aplicaciones distribuidas en múltiples niveles de abstracción
  • El paradigma cliente-servidor como arquitectura software
    El patrón cliente-servidor trata de proporcionar una arquitectura escalable para el desarrollo de aplicaciones distribuidas en la que intervienen sólo dos tipos de procesos: clientes y servidores
    La interacción entre el cliente y el servidor es síncrona
    El servidor
    Es pasivo, espera las peticiones de los clientes
    Cuando recibe peticiones, debe procesarlas y ofrecer una respuesta
    Suele ser diseñado con objetivos de eficiencia
    El cliente
    Es activo, tiene la iniciativa de iniciar el diálogo con el servidor enviando peticiones
    Por cada petición enviada, se debe obtener una respuesta
    Suele ser diseñado con el objetivo de interaccionar con el usuario final
  • El paradigma cliente-servidor como arquitectura de sistema
    Un sistema distribuido está compuesto por Nodos de procesamiento (ordenadores)
    Infraestructuras de comunicaciones (red)
    En muchas ocasiones se eligen características específicas sobre los nodos de procesamiento en términos de hardware, sistema operativo, prestaciones, etc.
    Estas características dependen del papel que el nodo esté destinado a representar
    En muchas ocasiones, los ordenadores que están destinados a almacenar procesos
    servidor (desde el punto de vista de arquitectura software) también son denominados servidores ellos mismos
    En este caso, por tanto, la palabra servidor se refiere a un equipo, no a un proceso
  • Tema II:
    CLIENTE - SERVIDOR
  • CLIENTE - SERVIDOR
    TCP es un protocolo orientado a conexión. No hay relaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelo cliente/servidor en las comunicaciones. Un servidor es una aplicación que ofrece un servicio a usuarios de Internet; un cliente es el que pide ese servicio. Una aplicación consta de una parte de servidor y una de cliente, que se pueden ejecutar en el mismo o en diferentes sistemas.
    Los usuarios invocan la parte cliente de la aplicación, que construye una solicitud para ese servicio y se la envía al servidor de la aplicación que usa TCP/IP como transporte.
    El servidor es un programa que recibe una solicitud, realiza el servicio requerido y devuelve los resultados en forma de una respuesta. Generalmente un servidor puede tratar múltiples peticiones(múltiples clientes) al mismo tiempo.
  • CLIENTE - SERVIDOR
    Algunos servidores esperan las solicitudes en puertos bien conocidos de modo que sus clientes saben a que zócalo IP deben dirigir sus peticiones. El cliente emplea un puerto arbitrario para comunicarse. Los clientes que se quieren comunicar con un servidor que no usa un puerto bien conocido tienen otro mecanismo para saber a qué puerto dirigirse. Este mecanismo podría usar un servicio de registro como Portmap, que utiliza un puerto bien conocido.
  • Clientes y servidores: quién hace qué?
    Las aplicaciones distribuidas existen para ofrecer unas funcionalidades al usuario
    La arquitectura abstracta de una aplicación distribuida cliente-servidor es siempre
    Capa de presentación
    Suele residir en el cliente
    El servidor puede tener funcionalidades de presentación menores
    Lógica de negocio:
    Puede residir en el servidor
    Puede residir en el cliente
    Puede residir parte en el cliente y parte en el servidor
    Capa de servicios:
    Es compartida, aunque suele tener más peso en el servidor
  • Ejemplos de aplicaciones cliente/servidor
    La capa de presentación requiere, entre otros:
    Capacidad para representar documentos HTML C
    Capacidad para representar imágenes en diferentes formatos C
    Capacidad para representar e interpretar otros tipos datos (pdf, applets, etc.) C
    La lógica de la aplicación requiere, entre otros:
    No hay mucha lógica de negocio en un servidor/cliente web clásico
    ¿Hay algo en un cliente o en un servidor web que no tenga que ver con
    Presentar los datos
    Proporcionar un servicio de lectura/codificación/envío de ficheros?
    La capa de servicios debe proporcionar, entre otros
    La implementación del protocolo HTTP
    Capacidad de acceder a ficheros identificados por un path HTTP S
    Comprimir y descomprimir un fichero (si se soporta el encodinggzip) C
  • Ejemplos de aplicaciones cliente/servidor
    Lógica de negocio en pseudocódigo
    VENTA (vendedor, numeroProductos, costeProducto){
    pagado = numeroProductos*costeProducto
    ingresos = pagado – pagado*0,1 – pagado*0,15
    InsertarEnTabla(TESORERIA, ingresos)
    BorrarDeTabla(INVENTARIO, numeroProductos)
    InsertarTabla(MATERIALES, numeroProductos, pagado*0,15)
    InsertarEnTabla(COMISIONES, vendedor, pagado*0,1)}
    Quién hace qué?
    Evidentemente, las tablas de datos deben estar en el servidor para que
    diferentes tiendas puedan compartirlas (servicio de BBDD)
    Evidentemente, en el cliente hay una GUI que permite al vendedor introducir su identificador, el número de productos vendidos y el coste por producto pactado
    ¿Quién implementa la lógica de negocio?
    ¿Qué pinta tiene el protocolo de nivel de aplicación que necesitamos?
    •Ambas respuestas están muy relacionadas
  • Ejemplos de aplicaciones cliente/servidor
    Solución 1: El servidor proporciona al cliente un servicio para hacer operaciones
    InsertarEnTabla(tabla, columna, valor)
    BorrarDeLaTabla(tabla, comuna, valor)
    Se define un protocolo de petición-respuesta para implementarlo
    Solución 2: El servidor proporciona al cliente un servicio para hacer operaciones
    ActualizarVenta(vendedor, numeroProductos, costePorProducto)
    Se define un protocolo de petición-respuesta para implementarlo
    Puede haber muchas otras soluciones intermedias
    Solución 1:
    ¿Donde reside la lógica de negocio, en el cliente o en el servidor?
    Solución 2:
    ¿Dónde reside la lógica de negocio, en el cliente o en el servidor?
  • Clientes gordos, flacos e híbridos
    Decimos que un cliente es
    Flaco (thin)
    Cuando no implementa en absoluto la lógica de la aplicación
    Es un mero intermediario entre el usuario y el servidor
    Requiere muy pocos recursos hardware
    Gordo (thick, fat)
    Cuando implementa la mayor parte de la lógica de la aplicación
    Procesa la información del usuario antes de comunicar con el servidor
    Requiere capacidad de proceso y, normalmente, capacidad de almacenamiento
    Híbrido (hybrid)
    Implementa una parte de la lógica de aplicación
    Si optamos por una arquitectura basada en un cliente flaco/híbrido
    El servidor será más complicado
    Si optamos por una arquitectura basada en un cliente gordo
    El servidor será más sencillo
  • Servidores con estados y sin estados
  • Servidores con estados y sin estados
  • Tema III:
    Mecanismos de caché en la arquitectura cliente-servidor
  • Mecanismos de Caché
    El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en duplicar (una parte de) los datos que posee un nodo, en otro distinto del original, con el objetivo de mejorar las prestaciones del acceso a los mismos
    Las cachés son un elemento esencial de las aplicaciones cliente-servidor
    Para comprender el funcionamiento de una caché observemos lo siguiente:
  • Mecanismos de Caché
  • Mecanismos de Caché
    El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en duplicar (una parte de) los datos que posee un nodo, en otro distinto del original, con el objetivo de mejorar las prestaciones del acceso a los mismos
    Las cachés son un elemento esencial de las aplicaciones cliente-servidor
    Para comprender el funcionamiento de una caché observemos lo siguiente:
  • Mecanismos de Caché
    El mecanismo de caché, en el contexto de las redes de ordenadores, consiste en
    duplicar (una parte de) los datos que posee un nodo, en otro distinto del original,
    con el objetivo de mejorar las prestaciones del acceso a los mismos
    Las cachés son un elemento esencial de las aplicaciones cliente-servidor
    Para comprender el funcionamiento de una caché observemos lo siguiente:
  • ¿Por qué la caché mejora la eficiencia?
    Mejora en términos de latencia
    Escenario: t1 = Latencia cliente-caché, t2 = Latencia caché-servidor
    Descarga de servidor (proceso inmediato): TServ = t1 + t2 + t2 + t1 = 2(t1+t2)
    Descarga de caché (proceso inmediato): TCache = t1 + t1 = 2t1
    La descarga desde la caché siempre tiene latencia de comunicación menor
    Mejora en términos de ancho de banda/tiempo de servicio
    Escenario: Fichero de 1G, 100 clientes que comparten la misma caché
    Sin caché: el servidor proporciona 100G bytes de datos a través de su línea
    Con caché: el servidor proporciona 1G byte de datos a través de su línea
    Mejora en términos de escalabilidad
    Parte del trabajo del servidor la hace la caché: el servidor soporta más clientes
    En general, la presencia de un sistema de caché permite que el cliente tenga “la respuesta” a sus peticiones de manera mucho más rápida