Fallas y Averías

Los términos falla y falta a menudo se usan mal. Una describe las situaciones a ser evitadas, mientras la otra describe el problema a ser evitado. Con el tiempo, avería ha llegado a ser definida en términos de servicios especificados provistos por un sistema. Esto evita definiciones circulares que involucren términos sinónimos como ser defecto, etc. Se dice que un sistema tiene una avería si el servicio que provee al usuario se desvía del cumplimiento con la especificación del sistema por un período de tiempo especificado. Mientras puede ser difícil llegar a una especificación no ambigua del servicio a ser provisto por cualquier sistema, el concepto de una especificación acordada es la más razonable de las opciones para definir servicio satisfactorio y la ausencia de servicio satisfactorio, avería.

La definición de avería como la desviación del servicio provisto por un sistema de la especificación del sistema elimina errores o fallas de “especificación”. Mientras esta aproximación puede estar evitando el problema al definirlo de todos modos, es importante tener alguna referencia para la definición de avería, y la especificación es una elección lógica. La especificación  puede considerarse como un límite a la región de interés del sistema, que se discute luego. Es importante reconocer que cada sistema tiene una  especificación explícita, la cual está escrita, y una especificación implícita que el sistema debería al menos comportarse tan bien como una persona razonable podría esperar basada en experiencias con sistemas similares y con el mundo en general. Claramente, es importante hacer la especificación tan explícita como sea posible.

Se ha convertido en una práctica definir fallas en términos de avería. El concepto más cercano al entendimiento común de la palabra falla es una que define a una falla como la causa adjudicada de una avería. Esto encaja con una aplicación común del verbo fallar, que involucra determinar causa o culpa anexa (affixing blame). Sin embargo, esto requiere entender de como se producen las averías. Una forma alternativa de ver a las averías es considerarlas fallas en otros sistemas que interactuan con el sistema bajo consideración, tanto un sistema interno al sistema considerado, un componente del sistema considerado, o un sistema externo que interactua con el sistema considerado (el entorno). En el primer caso, la conexión entre averías y fallas es causa; en el segundo es nivel de abstracción o ubicación.

Las ventajas de definir averías como fallas de componentes/sistemas interactuantes son:

1.  Uno puede considerar fallas sin la necesidad de establecer una conexión directa con una avería, así se puede tratar fallas que no causan averías, es decir, el sistema es naturalmente tolerante a fallas.

2.  La definición de una falla es la misma que la de una avería con la única diferencia de los límites del sistema o subsistema relevante.

Esto significa que podemos considerar a un defecto interno obvio como una falla sin tener que establecer una relación causal entre el defecto y una avería en el límite del sistema.

Con lo antes mencionado, una falla se definirá como la avería de (1) un componente del sistema, (2) un subsistema del sistema, o (3) otro sistema que ha interactuado o está interactuando con el sistema considerado. Cada falla es una avería desde algún punto de vista. Una avería puede conducir a otras fallas, o a otra avería, o a nada.

Un sistema con fallas que puede continuar proveyendo su servicio, no falla. Tal sistema se dice que es tolerante a fallas. De este modo, una motivación importante para diferenciar entre averías y fallas es la necesidad de describir la tolerancia a fallas de un sistema. Un observador que inspeccione los componentes internos de un sistema podría decir que el componente defectuoso ha fallado, porque el punto de vista del observador no está a un nivel de detalle más bajo. El efecto observable de una falla en el límite del sistema se llama síntoma. El síntoma más extremo de una falla es una avería, pero también podría ser algo tan benigno como una lectura alta en un termómetro. Los síntomas se discutirán luego en detalle.

Consideremos un sistema de computación que corra un programa de control de la temperatura de una caldera al calcular la llama del quemador para la caldera. Si un bit de memoria se pone en uno, es una falla. Si la falla de la memoria afecta la operación del programa de forma tal que la salida del sistema de computación hace que la temperatura de la caldera se eleve fuera de la zona normal, es una avería en el sistema de computación y una falla en el sistema general de la caldera. Si hay un termómetro mostrando la temperatura de la caldera, y su aguja se mueve hacia la zona “amarilla” (anormal pero aceptable) eso es un síntoma de la falla del sistema. Por otra parte, si la caldera explota por el cálculo defectuoso de la llama, eso es una avería (catastrófica) del sistema.

Las razones para la falla de la memoria son múltiples. El chip usado podría haber sido fabricado según la especificación (falla de fabricación), el diseño de hardware podría haber causado que se aplicara demasiado voltaje al chip (falla de diseño del sistema), el diseño del chip puede hacer propensas tales fallas (falla de diseño del chip), un ingeniero puede haber invertido inadvertidamente dos cables al realizar mantenimiento (falla de mantenimiento).

Mis muy estimamos compañeros, les dejo aquí el link de una presentación electrónica, en donde abordaremos el tema del protocolo TCP, espero les sea de utilidad esta información, les mando saludos y un caluroso abrazo


LINK

https://www.dropbox.com/s/38kg23pmljewbfc/tcp.ppt?dl=0


:) ;)

ESTA VEZ LES COMENTARE SOBRE EL PROTOCOLO UDP (Protocolo de Datagramas de Usuarios).


UDP envía un paquete de data a la vez (llamado datagrama) a otros sistemas y no suministra una conexión virtual como lo hace TCP, asimismo UDP no provee las mismas garantías que tiene TCP, esto significa que puede darse el caso de que los paquetes se pierdan o bien no sean reconstruidos en la forma adecuada.

§  La utilidad de utilizar UDP en vez de TCP,  Si UDP no es confiable, esta se basa en que TCP tiene un alto solapamiento en la conexión comparado con UDP, lo que hace que TCP sea mas lento que UDP. Para aplicaciones donde la velocidad de ejecución es mas importante que la confiabilidad, UDP tiene mas sentido. Algunos ejemplos incluye audio y video en la internet y algunas aplicaciones telefónicas.

ESTAS SON CARACTERÍSTICAS DE UDP

5.2.- Necesidad de manejar varios protocolos


Una condición que se necesita para permitir que la arquitectura por niveles funcione adecuadamente es que cada nivel debe saber lo que recibe de un nivel por encima o por debajo.Para simplificar esta tarea, cada nivel añade un bloque de datos al principio y al final del mensaje que indica que nivel esta implicado, además del resto de información que los otros niveles y la máquina que lo va a recibir necesitan para manejar el mensaje de forma adecuada. Los datos dentro del mensaje se ignoran. Esto se denomina encapsulación, ya que cada nivel añade una cápsula de información en torno a los datos originales.

APLICACIÓN
TRANSPORTE
INTERNET
INTERFACE DE RED
FISICO

La necesidad de existencia de protocolos posibilita que los componentes de software separados pueden desarrollarse independientemente e implementarse en diferentes lenguajes de programación sobre computadores que quizás tengan diferentes representaciones internas de datos.
Un protocolo esta implementado por dos módulos software ubicados en el emisor y receptor.un proceso transmitirá un mensaje a otro efectuando una llamada al modulo pasando  el mensaje en cierto formato.

5.2.- Necesidad de manejar varios protocolos


Una condición que se necesita para permitir que la arquitectura por niveles funcione adecuadamente es que cada nivel debe saber lo que recibe de un nivel por encima o por debajo.Para simplificar esta tarea, cada nivel añade un bloque de datos al principio y al final del mensaje que indica que nivel esta implicado, además del resto de información que los otros niveles y la máquina que lo va a recibir necesitan para manejar el mensaje de forma adecuada. Los datos dentro del mensaje se ignoran. Esto se denomina encapsulación, ya que cada nivel añade una cápsula de información en torno a los datos originales.

APLICACIÓN
TRANSPORTE
INTERNET
INTERFACE DE RED
FISICO

La necesidad de existencia de protocolos posibilita que los componentes de software separados pueden desarrollarse independientemente e implementarse en diferentes lenguajes de programación sobre computadores que quizás tengan diferentes representaciones internas de datos.
Un protocolo esta implementado por dos módulos software ubicados en el emisor y receptor.un proceso transmitirá un mensaje a otro efectuando una llamada al modulo pasando  el mensaje en cierto formato.