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 clave

La 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 EMULE

CARACTERISTICAS DE ARES

CARACTERISTICAS EMULE

Descarga de archivos a gran velocidad desde varias fuentes: Ares se encarga

Ofuscacin del protocolo. La Ofuscacin de Protocolo

de buscar el mximo nmero de usuarios que estn compartiendo del archivo que

esconda su protocolo al comunicarse con el servidor u otros client

queremos descargar. De este modo, la velocidad de descarga ser mayor, incluso si la

conexin de los usuarios fuente es poco potente.

Compartir chunks. Los archivos se pueden compartir

bajados. Una vez que un usuario tiene una parte de 9500 KB que

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

Deteccin de errores. utiliza algoritmos de deteccin d

imposible que se corrompan los archivos que se descargan.

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.

Transferencias comprimidas. Cada vez que transm

biblioteca zlib para ahorrar ancho de banda, de forma completame

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.

Independencia de los nombres de archivo. Utiliza un si

sus contenidos y no por la denominacin, por ello puede ser que d

con el nombre. Es posible consultar todos los nombres que se le a

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.

Sistema de crditos y colas. Se recompensa a los us

dndoles ms prioridad a la hora de progresar dentro de la co

calculan con base en la cantidad de datos transferidos entre dos c

Chat de comparticin de archivos: podrs charlar con otros usuarios de Ares para la valoracin de las peticiones de clientes y su posicin en la cola.
preguntar dudas, pedir archivos y recomendar descargas sin salir del programa.

Comentarios para los archivos permite calificar la calidad

Mensajes directos entre usuarios: Ares puede actuar como si de un cliente sobre cada archivo haciendo que otros usuarios los puedan leer.
Messenger se tratara gracias al servicio de mensajera privada que ofrece desde el mdulo
de chat.

Filtrado bsico de IPs. Los rangos de IP para filtra

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.

llamado ipfilter.dat el cul es almacenado en la carpeta de instala

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-basesde-datos2.shtml
http://sedici.unlp.edu.ar/bitstream/handle/10915/23586/Documento_com
pleto.pdf?sequence=1
http://laurel.datsi.fi.upm.es/_media/docencia/asignaturas/sd/sincronizaci
on-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