diff --git a/redes/2.org b/redes/2.org new file mode 100644 index 0000000..4c335c6 --- /dev/null +++ b/redes/2.org @@ -0,0 +1,14 @@ +#+title: Clase 2 +#+author: Fede +#+email: federico.nicolas.polidoro@gmail.com + +* Inicio clase +Es una materia que estaba basada enn la parte de material viejo de la materia o trabajar en ver tecnologias nuevas asi tenemos una idea de que hacer con el antiguo conocimiento y asi saber como usarlo en el mundo actual + +El tp que hay que entregar el 28 tiene validez de parcial. + + +* Nota +La parte del trabajo tiene validez de final + +Tenemos marcado donde estan los grupos el nuestro? diff --git a/redes/guia-resolucion.org b/redes/guia-resolucion.org new file mode 100644 index 0000000..0e071d0 --- /dev/null +++ b/redes/guia-resolucion.org @@ -0,0 +1,209 @@ +#+TITLE: Guía de Resolución - Trabajo Práctico Integrador Unidad 1 +#+SUBTITLE: Diseño y Evaluación de Arquitecturas Distribuidas en Redes WAN (Distribuidora Sudamericana S.A.) +#+AUTHOR: Federico + +* INTRODUCCIÓN Y METODOLOGÍA DE TRABAJO + Esta guía está diseñada en formato Org-mode para estructurar el desarrollo del Trabajo Práctico Integrador, asegurando el cumplimiento estricto de los requisitos para obtener la calificación máxima (*Sobresaliente - 10*) de acuerdo con la rúbrica oficial. + + ** Instrucciones de uso: + - Copia este archivo a tu directorio de estudio o repositorio Git. + - Abre el archivo en Emacs (u otro editor compatible con Org-mode) para gestionar el estado de las tareas (=TODO=, =EN-PROGRESO=, =ENTREGADO=). + - Utiliza los bloques de código y las plantillas provistas para redactar tu informe final. + +* FASE 1: ALINEACIÓN NEGOCIO-TECNOLOGÍA (MODELO TOP-DOWN) [0/3] + :PROPERTIES: + :Capas: Negocio, Aplicación, Datos, Red, Tecnología + :Rúbrica: Integra las 5 capas vinculando el diseño al Modelo I-P-O y principios de BPR. + :END: + + ** TODO [ ] Modelar el Proceso Actual vs. Proceso Propuesto (BPR) + Distribuidora Sudamericana S.A. actualmente utiliza "sneaker-net", enviando 1.000 CDs físicos mediante correo tradicional, lo que genera demoras de 3 a 5 días hábiles y colapsos nocturnos por sincronizaciones ineficientes. + + *Guía de Resolución:* + - Diseñar un diagrama de flujo o matriz que muestre el contraste. + - Identificar los cuellos de botella clave del proceso actual. + + ** TODO [ ] Completar la Matriz I-P-O (Input-Process-Output) por Capa + Asegurar que las 5 capas del modelo Top-Down estén alineadas estructuralmente. + + | Capa | Entrada (Input) | Proceso (Process) | Salida (Output) | + |--------------+-------------------------------------+---------------------------------------------------------+---------------------------------------| + | *Negocio* | Pedidos de sucursales, stock | Procesamiento de ventas, auto-logística | Disponibilidad de stock, reportes irt | + | *Aplicación* | Transacciones locales de ventas CSV | Ejecución de reglas de negocio | Envío asíncrono de tramas de venta | + | *Datos* | Base de datos local | Sincronización diferencial nocturna mediante middleware | Consistencia global de datos | + | *Red* | Tráfico de red LAN local | Enrutamiento seguro a través de enlaces WAN (VPN) | Transporte de datos y mínima latencia | + | *Tecnología* | Hardware local, interfaces físicas | Modulación/Demodulación en CSU/DSU | Portadora física de bits activa | + + ** TODO [ ] Redactar el Análisis Crítico: La Paradoja de la Productividad + Explicar formalmente por qué la tecnología por sí sola no genera ROI si no está precedida por la Reingeniería de Procesos de Negocio (BPR). + + *Puntos Teóricos Innegociables para el "10":* + - *Strassmann:* "La computadora es una máquina que amplifica la eficiencia o la ineficiencia empresarial". Si automatizas un caos, obtienes un "caos automatizado" a mayor costo. + - *Brynjolfsson:* La paradoja ocurre por la falta de rediseño de procesos, falta de capacitación y fallas de medición. + - *Conclusión:* Justificar cómo la red integrada habilita una entrega oportuna al usuario correcto, rompiendo la rigidez legacy. + +* FASE 2: ARQUITECTURA DE SISTEMAS Y ESTRATEGIA DE MIDDLEWARE [0/3] + :PROPERTIES: + :Rúbrica: Justifica técnicamente la Integración Horizontal (Interface 3) y el uso de TP Monitors. + :END: + + ** TODO [ ] Estructura de N-Capas + Justificar la separación lógica para aislar la complejidad técnica de la interfaz, el negocio y los datos. + + *Estructura Propuesta:* + - *Capa de Presentación:* Cliente ligero o interfaz web en sucursal. + - *Capa de Lógica de Negocio (Aplicación):* Servidor centralizado (o clúster) que procesa las reglas operativas de Distribuidora Sudamericana. + - *Capa de Datos:* Motor de Base de Datos relacional central que almacena transacciones históricas e inventarios consolidados. + + ** TODO [ ] Diseñar la Estrategia de Middleware (Sincrónico vs. Asíncrono) + Diferenciar claramente los dos escenarios requeridos: + + 1. *Middleware para Transacciones de Ventas (Sincrónico - Tiempo Real):* + - *Tecnología:* *TP Monitors (Transaction Processing Monitors)* bajo el estándar *XA*. + - *Justificación:* Garantizar las propiedades *ACID* (Atomicidad, Consistencia, Aislamiento, Durabilidad) mediante un protocolo de *Two-Phase Commit (2PC)*. Si un cliente en la sucursal de Bogotá compra el último stock, la transacción debe ser consistente en la central antes de completarse, evitando dobles ventas. + 2. *Middleware para Actualizaciones de Datos/Software (Asíncrono - Interface 3):* + - *Tecnología:* *MOM (Message-Oriented Middleware)* basado en el patrón Publicación/Suscripción (Publish/Subscribe). + - *Modelo Histórico:* Inspirado en *Castanet de Marimba* (distribución eficiente de actualizaciones incrementales de software/datos mediante canales de suscripción). + - *Justificación:* Sustituye el envío de los 1.000 CDs. Las sucursales se "suscriben" al canal de actualizaciones de precios y catálogos. El MOM gestiona las descargas de manera asíncrona, segura, permitiendo reanudar descargas interrumpidas sin colapsar el ancho de banda WAN. + + ** TODO [ ] Dimensionamiento de Procesamiento (Smartsizing) + Justificar por qué *Smartsizing* o *Rightsizing* es la mejor alternativa frente a arquitecturas monolíticas centralizadas (Downsizing extremo) o sistemas pesados distribuidos ineficientemente. + + *Argumentación:* + - El *Smartsizing* permite ubicar la capacidad de cómputo donde el negocio lo requiere. Las sucursales manejan la interfaz y la validación básica local, mientras que el procesamiento pesado de inventarios consolidados y la lógica transaccional residen en el servidor de aplicación central. + +* FASE 3: DISEÑO DE LA INFRAESTRUCTURA FÍSICA WAN [0/2] + :PROPERTIES: + :Rúbrica: Define correctamente la cadena DTE-DCE, estándares de interfaz (V.35/G.703) y punto de demarcación. + :END: + + ** TODO [ ] Diagramar y Explicar los Componentes de la Red WAN + Definir rigurosamente cada componente en la cadena de comunicación desde la Sucursal hasta la Oficina Central (CO). + + *Glosario Técnico Obligatorio:* + - *CPE (Customer Premises Equipment):* Equipamiento de comunicaciones ubicado físicamente en las oficinas de Distribuidora Sudamericana (ej. Routers, switches). + - *DTE (Data Terminal Equipment):* El dispositivo final del cliente que genera los datos (ej. Router de borde). Interfaz típica: *V.35* para conexiones síncronas de alta velocidad. + - *DCE (Data Circuit-terminating Equipment):* El dispositivo que adapta las señales para su transmisión a través de la red WAN (ej. CSU/DSU, módem). Interfaz típica: *G.703* en el lado de la línea de transmisión digital (E1/T1). + - *Punto de Demarcación:* Límite físico y de responsabilidad contractual entre Distribuidora Sudamericana y el Carrier (ISP). + - *Bucle Local (Última Milla):* Cableado físico que conecta las instalaciones del cliente (CPE) con la Oficina Central (CO) del proveedor de servicios. + - *CO (Central Office):* Punto de presencia local del ISP que recibe los bucles locales y realiza la conmutación hacia el backbone WAN global. + - *CSU/DSU (Channel Service Unit/Data Service Unit):* Dispositivo DCE digital que adapta la interfaz física del Router (DTE) a las tramas de la línea portadora síncrona (ej. T1/E1). + + ** TODO [ ] Completar la Tabla Comparativa de Conectividad WAN + Analizar críticamente las tres opciones tecnológicas para la interconexión de las 5 sucursales y la sede central. + + | Criterio | Líneas Dedicadas (T1/E1) | Frame Relay | VPN sobre Internet | + |----------+--------------------------+-------------+--------------------| + | *Ancho de Banda* | Fijo y garantizado (1.544 / 2.048 Mbps) | Compartido (CIR garantizado por PVC) | Variable (dependiente de la conexión local a Internet) | + | *Costo* | Extremadamente alto (costo por milla/distancia) | Moderado (costo según CIR seleccionado) | Muy bajo (solo requiere accesos a Internet locales) | + | *Seguridad* | Máxima (física, canal exclusivo) | Alta (aislamiento lógico en circuitos virtuales) | Alta si se implementa cifrado robusto (IPsec) | + | *Confiabilidad (SLA)* | Excelente (control total del enlace síncrono) | Muy buena (SLA asegurado por el carrier) | Variable (SLA de "mejor esfuerzo" en la red pública) | + | *Recomendación* | Descartado para todas las sucursales por costos prohibitivos | Adecuado como enlace principal para transacciones críticas | Recomendado como enlace principal (o respaldo) con IPsec | + +* FASE 4: MODELADO DE ALGORITMOS DE ENLACE DE DATOS [0/1] + :PROPERTIES: + :Rúbrica: Modelado impecable del bit-stuffing asegurando la unicidad del flag 01111110. + :END: + + ** TODO [ ] Implementar el Algoritmo de Bit-Stuffing (Opción A) + Para asegurar la "transparencia de datos" en enlaces de datos síncronos como HDLC, el emisor debe insertar un '0' después de detectar de forma consecutiva cinco bits '1' en la carga útil. Esto evita que los datos del usuario simulen accidentalmente la bandera de delimitación de trama (=01111110=). + + *Código Java para el Emisor (Bit-Stuffing):* + #+BEGIN_SRC java :results output :exports both + public class HDLCBitStuffing { + private static final String FLAG = "01111110"; + + /** + * Recibe una cadena de caracteres con bits '1' y '0', + * aplica la lógica de bit-stuffing de HDLC e inserta las banderas de inicio/fin. + */ + public static String bitStuffingEmisor(String datosCrudos) { + StringBuilder datosProcesados = new StringBuilder(); + int conteoUnos = 0; + + for (int i = 0; i < datosCrudos.length(); i++) { + char bit = datosCrudos.charAt(i); + if (bit == '1') { + conteoUnos++; + datosProcesados.append(bit); + if (conteoUnos == 5) { + datosProcesados.append('0'); // Inserción del bit de relleno (Stuffing) + conteoUnos = 0; + } + } else if (bit == '0') { + conteoUnos = 0; + datosProcesados.append(bit); + } else { + throw new IllegalArgumentException("Dato inválido: solo se permiten bits '1' y '0'."); + } + } + return FLAG + datosProcesados.toString() + FLAG; + } + } + #+END_SRC + + #+RESULTS: + + *Código Java para el Receptor (Bit-Destuffing):* + #+BEGIN_SRC java :results output :exports both + public class HDLCBitDestuffing { + private static final String FLAG = "01111110"; + + /** + * Remueve las banderas de delimitación e identifica los '0's de relleno + * insertados después de cinco '1's consecutivos para recuperar el payload original. + */ + public static String bitDestuffingReceptor(String tramaHDLC) { + if (!tramaHDLC.startsWith(FLAG) || !tramaHDLC.endsWith(FLAG) || tramaHDLC.length() < 16) { + throw new IllegalArgumentException("Trama inválida: falta o está corrupto el delimitador de trama."); + } + + // Extraer la carga útil removiendo las banderas de inicio y fin + String payloadConStuffing = tramaHDLC.substring(FLAG.length(), tramaHDLC.length() - FLAG.length()); + StringBuilder datosRecuperados = new StringBuilder(); + int conteoUnos = 0; + int i = 0; + + while (i < payloadConStuffing.length()) { + char bit = payloadConStuffing.charAt(i); + if (bit == '1') { + conteoUnos++; + datosRecuperados.append(bit); + if (conteoUnos == 5) { + // El siguiente bit obligatoriamente es el '0' de stuffing y debe ser ignorado + if (i + 1 < payloadConStuffing.length() && payloadConStuffing.charAt(i + 1) == '0') { + i++; // Ignorar el '0' de stuffing + } else if (i + 1 < payloadConStuffing.length() && payloadConStuffing.charAt(i + 1) == '1') { + throw new IllegalStateException("Error en trama: Se detectaron más de 5 unos consecutivos sin bit de relleno."); + } + conteoUnos = 0; + } + } else { + conteoUnos = 0; + datosRecuperados.append(bit); + } + i++; + } + return datosRecuperados.toString(); + } + } + #+END_SRC + + #+RESULTS: + + *Clase de Prueba Interactiva (Main):* + #+BEGIN_SRC java :results output :exports both + public class HDLCApp { + public static void main(String[] args) { + String mensaje = "0111111011111101"; // Carga útil con patrones idénticos al Flag + System.out.println("Mensaje original: " + mensaje); + + String tramaConStuffing = HDLCBitStuffing.bitStuffingEmisor(mensaje); + System.out.println("Trama con Stuffing: " + tramaConStuffing); + + String mensajeRecuperado = HDLCBitDestuffing.bitDestuffingReceptor(tramaConStuffing); + System.out.println("Payload recuperado: " + mensajeRecuperado); + System.out.println("¿Es correcto? " + mensaje.equals(mensajeRecuperado)); + } + } + #+END_SRC