Situacin 1.

Disee y describa un protocolo del nivel de aplicacin para ser usado entre un cajero automtico y el computador central del banco. El protocolo debe permitir que se verifique la tarjeta y la clave del usuario, que se consulte el balance de la cuenta (que se mantiene en el computador central), y que se realicen reintegros de una cuenta (es decir, dinero reintegrado al usuario). Las entidades del protocolo deben ser capaces de resolver el problema tan comn de que no haya suficiente dinero en la cuenta para cubrir el reintegro. Especifique el protocolo listando los mensajes intercambiados y la accin tomada por el cajero automtico o el computador central del banco ante la transmisin o recepcin de mensajes. Esboce la operacin de su protocolo para el caso de un reintegro sencillo sin errores, utilizando un diagrama de estados.

ASPECTOS CONCEPTUALES

COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR

El modelo Cliente/Servidor es un modelo basado en la idea del servicio, en el que el cliente es un proceso consumidor de servicios y el servidor es un proceso proveedor de servicios. Adems esta relacin est establecida en funcin del intercambio de mensajes que es el nico elemento de acoplamiento entre ambos.

Descomposicin o arquitectura de niveles, consiste en separar los elementos estructurales de esta tecnologa en funcin de aspectos ms funcionales de la misma: Nivel de Presentacin: Agrupa a todos los elementos asociados al componente Cliente. Nivel de Aplicacin: Agrupa a todos los elementos asociados al componente Servidor. Nivel de comunicacin: Agrupa a todos los elementos que hacen posible la comunicacin entre los componentes Cliente y servidor. Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.

Transacciones, integridad y seguridad

Una transaccin es una coleccin de operaciones que realiza una nica funcin lgica. Cada transaccin es una unidad de atomicidad (debe ocurrir completa o no ocurrir). Los algoritmos para asegurar la consistencia de la Base de Datos, utilizando las transacciones, incluyen: Acciones tomadas durante el procesamiento normal de las transacciones que aseguran la existencia de informacin suficiente para asegurar la recuperacin de fallos. Acciones tomadas a continuacin de un fallo, para asegurar la consistencia de la Base de Datos.

Las transacciones transforman la base de datos de un estado consistente hacia otro tambin consistente. Pero se debe tener en cuenta que la consistencia de la base de datos puede ser violada durante la ejecucin de la transaccin. Las cuatro propiedades bsicas de una transaccin, son:

1. Atomicidad: la propiedad del todo o nada; una transaccin es una unidad indivisible 2. Consistencia: las transacciones transforman la base de datos de un estado consistente a otro tambin consistente 3. Independencia: las transacciones se ejecutan independientemente una de las otras (los efectos parciales de una transaccin incompleta no son visibles para el resto de las transacciones) 4. Durabilidad (tambin llamada persistencia): los efectos de transacciones que ya fueron completadas (cometidas) son almacenados permanentemente en la base de datos y no pueden ser desecho.En un ambiente de base de datos distribuida, una transaccin puede acceder a datos que estn almacenados en ms de un sitio de la red. Cada transaccin es dividida en una serie de sub-transacciones, una por cada sitio en donde existan datos que la transaccin original necesita procesar. Existen dos mecanismos utilizados para asegurar la atomicidad de las transacciones: Basado en bitcora Doble paginacin

Protocolos de Commit Atmicos (ACP)

Un modelo comn para una transaccin distribuida se centra en un proceso, llamado coordinador, que se ejecuta en el sitio en donde la transaccin se crea, y un conjunto de procesos, llamados localidades, que se ejecutan en distintos sitios que deben ser accedidos por la transaccin. Para garantizar la atomicidad, es preciso que en todas las localidades en las que se haya ejecutado la transaccin distribuida T coincidan en el resultado final de la ejecucin. T debe quedar ejecutada o abortada en todas las localidades; Para garantizar esta propiedad, el coordinador de transacciones encargado de T debe ejecutar un protocolo de commit.Se han propuesto una gran variedad de protocolos. Entre los ms importantes incluimos al protocolo de dos fases (2PC), dos variaciones de ste llamadas protocolo pesimista (PrA) y optimista (PrC), y por ltimo al protocolo de tres fases (3PC). Segn la funcionalidad de cada uno, los protocolos de commit requieren intercambiar mensajes, a travs de distintas fases, entre sitios participantes donde la transaccin distribuida es ejecutada. Por lo tanto, son generados varios registros en memoria estable, alguno de los cuales son grabados a disco de manera sincrnica.

Caractersticas del Protocolo clsico two-phase-commit (2PC)

Proceso que ejecuta transaccin acta de coordinador Requiere almacenamiento estable: (nunca pierde la informacin.) Uso de dos discos: se escribe primero en uno y luego en otro.

Mensajes intercambiados en two-phase commit:

canCommit?(): El coordinador consulta a los servidores. doCommit(): El coordinador solicita a los servidores el procesamiento de las modificaciones. doAbort(): El coordinador indica a los servidores que la operacin se aborta. haveCommitted(): El servidor indica que ha completado la operacin. getDecision(): El servidor indica si puede realizar la accin.Coordinador (Monitor Transaccional):

Escribir canCommit?() en memoria estable. Mandar a subordinados. canCommit?() Recoger las respuestas getDecision() Si todos ok => doCommit() Si alguno abort o no responde=>doAbort() Escribir resolucin en memoria estable Mandar resolucin

Subordinados (Servidores/objetos transaccionales):

Recibir canCommit?()Decidir respuesta y grabar en memoria estable Mandar respuesta: getDecision() Recibir resolucin Escribir resolucin en memoria estable Llevar a cabo resolucin:doCommit()=> hacer cambios permanentes doAbort() => deshacer cambios

Protocolo de tres fases

El problema fundamental con los protocolos descriptos anteriormente es que las localidades podran bloquearse en el caso de un fallo hasta que el sitio que fall se recupere. Por ejemplo, si el coordinador falla luego de iniciar el protocolo pero antes de comunicar su decisin a cada localidad, stas se bloquearn hasta que el coordinador se recupere y les informe su decisin. Durante el tiempo en que las localidades estn bloqueadas, continan manteniendo recursos del sistema, como por ejemplo locks sobre algunos items de datos, haciendo que no estn disponibles para otras transacciones. Para atacar el problema de bloqueo, fue propuesto el protocolo de tres fases (3PC). Activa la capacidad de no bloquearse agregando una nueva fase: "precommit" entre las dos fases definidas en el protocolo de dos fases. Aqu se obtiene una decisin preliminar, que ser comunicada a todos las localidades participantes de la transaccin, permitiendo que la decisin global del destino de la transaccin se genere independientemente de un posible fallo del coordinador. Cabe destacar, que el precio de obtener la funcionalidad de no bloquearse, es que existir un nmero mayor de mensajes que se intercambiarn entre el coordinador y las localidades, ya que existe una fase ms. Por lo tanto, tambin necesitarn escribir registros adicionales en memoria estable, durante la fase de "precommit".

El protocolo de tres fases requiere que:

No pueda ocurrir una fragmentacin de la red. Debe haber al menos una localidad funcionando en cualquier punto. En cualquier punto, como mximo un numero K de participantes pueden caer simultneamente (siendo K un parmetro que indica la resistencia del protocolo a fallos en localidades).

Existe una variante del 2PC denominada Three-Phase Commit Fases: El coordinador transmite canCommit?() a todos los servidores. Los servidores responden con getDecision() al coordinador. El coordinador recolecta las respuestas y manda: preCommit() : Si todos aceptan. doAbort() : Si todos aceptan. Los servidores con un asentimiento. Cuando todos los asentimientos han sido recibidos entonces transmite doCommit() Es no bloqueante y ms robusta ante fallos que el 2PC

DESARROLLO DE LA ACTIVIDAD

Paso Inicial: Verificacin de usuario y claveLa informacin existente en la tarjeta es contrastada con la digitada por el usuario.A nivel de servidor, la comunicacin es procesada de la siguiente manera: El coordinador transmite canCommit?( La informacin ingresada es correcta)El servidor verifica la informacin contenida en la tarjeta y acepta o declina la operacin, enviando el mensaje correspondiente.Si fue aceptada la operacin, se procede a solicitar la clave del producto. El coordinador transmite canCommit?( La informacin ingresada es correcta)El servidor verifica la informacin ingresada y acepta o declina la operacin, enviando el mensaje correspondiente (Aceptacin o rechazo).En caso de ser errnea la informacin, se solicita nuevamente la clave, hasta un nmero definido de intentos; bloqueando la tarjeta.En caso de ser aceptada la transaccin, se despliega el men de servicios ofertados por la entidad financiera.

Cuando el cliente selecciona la opcin de consulta de su saldo: Se solicita la informacin relacionada con movimientos de cuenta que deben ser consultados en la base de datos.

La informacin es presentada por el servidor al usuario, previa verificacin de su existencia. Para el caso de los reintegros, es necesario realizar una serie de verificaciones por parte del servidor para culminar la operacin; La solicitud de reintegros de dinero se procede de la siguiente manera:

Verificacin por parte del servidor sobre la disponibilidad de este servicio para el usuario. Verificacin de disponibilidad de dinero en la cuenta origen para realizar el reintegro al usuario. Habiendo realizado las verificaciones necesarias, se presentar la respuesta al usuario, aprobando o declinando su solicitud. Para el caso de aprobacin de transaccin, se muestra el nuevo saldo de la cuenta del usuario; en caso contrario se mostrar al usuario el motivo del rechazo de su solicitud.

CUADRO COMPARATIVO ARES EMULECARACTERISTICAS DE ARES

CARACTERISTICAS EMULE

Descarga de archivos a gran velocidad desde varias fuentes: Ares se encarga de buscar el mximo nmero de usuarios que estn compartiendo del archivo que queremos descargar. De este modo, la velocidad de descarga ser mayor, incluso si la conexin de los usuarios fuente es poco potente.

Bsqueda avanzada: la bsqueda de Ares puede filtrar archivos por tipo: audio, vdeo, documentos, software, imgenes, etc. Adems, existen filtros personalizados para cada tipo de archivo.

Compatibilidad con Bittorrent: Ares es compatible con la red Bittorrent, una de las redes P2P ms populares en cuanto al intercambio de series, pelculas y software.

Potente organizador de archivos: la Biblioteca de Ares organiza todas nuestras descargas de forma automtica, clasificndolas y etiquetndolas para una mejor localizacin. Posee herramientas de etiquetado y un buscador integrado.

Reproductor multimedia integrado: con el reproductor multimedia integrado en Ares podrs disfrutar de tus archivos multimedia a la vez que descargas, navegas y chateas en Ares. El reproductor tambin incluye la posibilidad de agregar radios online.

Chat de comparticin de archivos: podrs charlar con otros usuarios de Ares para preguntar dudas, pedir archivos y recomendar descargas sin salir del programa.

Mensajes directos entre usuarios:Ares puede actuar como si de un cliente Messenger se tratara gracias al servicio de mensajera privada que ofrece desde el mdulo de chat.

Mltiples ventanas de bsqueda:con Ares es posible realizar varias bsquedas de contenido desde varias ventanas simultneamente mostradas en pestaas.

Compartir archivos detrs de un firewall (cortafuegos):a partir de Ares 1.9.0, se pueden compartir datos entre dos o ms usuarios que estn detrs de un cortafuegos, siempre y cuando todos ellos tengan una versin superior o igual a Ares 1.9.0.

Ofuscacin del protocolo. La Ofuscacin de Protocolo es una caracterstica que hace que esconda su protocolo al comunicarse con el servidor u otros clientes.

Compartirchunks.Losarchivosse pueden compartir aunque no estn completamente bajados. Una vez que un usuario tiene una parte de 9500KBque ha podido ser verificada, la pone a disposicin del resto de la red.

Deteccin de errores. utilizaalgoritmosde deteccin de errores. De esta manera es casi imposible que secorrompanlos archivos que se descargan.

Transferencias comprimidas.Cada vez que transmite datos, los comprime con la bibliotecazlibpara ahorrar ancho de banda, de forma completamente transparente al usuario.

Independencia de los nombres de archivo. Utiliza un sistema que reconoce los archivos por sus contenidos y no por la denominacin, por ello puede ser que descargues algo que no corresponda con el nombre. Es posible consultar todos los nombres que se le asignan al mismo archivo.

Sistema de crditos y colas.Se recompensa a los usuarios que han subido ms datos dndoles ms prioridad a la hora de progresar dentro de la cola de espera. Los modificadores se calculan con base en la cantidad de datos transferidos entre dos clientes, el cual directamente afecta a la valoracin de las peticiones de clientes y su posicin en la cola.

Comentarios para los archivos permite calificar la calidad de un archivo y escribir comentarios sobre cada archivo haciendo que otros usuarios los puedan leer.

Filtrado bsico de IPs. Los rangos de IP para filtrar son almacenados en un archivo llamadoipfilter.datel cul es almacenado en la carpeta de instalacin del emule.

REFERENCIAS BIBLIOGRAFICAS

http://docs.oracle.com/cd/E24842_01/html/820-2981/ipov-6.html

http://www.monografias.com/trabajos81/las-bases-de-datos/las-bases-de-datos2.shtml http://sedici.unlp.edu.ar/bitstream/handle/10915/23586/Documento_completo.pdf?sequence=1 http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sd/sincronizacion-transacciones-1pp.pdf http://aresgalaxy.es/caracteristicas-2/ http://emuleplus.info/forum/lofiversion/index.php?t4476.html http://emule.com.es/articulos/caracteristicas-de-emule