Nuevo contenido ATR2 SETR1 DAD

This commit is contained in:
Jose
2025-02-03 15:02:35 +01:00
parent e5a777021c
commit ebb4940d41
11 changed files with 190 additions and 36 deletions

View File

@@ -26,5 +26,6 @@
"workspaces": false, "workspaces": false,
"file-recovery": true, "file-recovery": true,
"publish": false, "publish": false,
"sync": false "sync": false,
"webviewer": false
} }

View File

@@ -4,37 +4,24 @@
"type": "split", "type": "split",
"children": [ "children": [
{ {
"id": "a72b4500445db8bf", "id": "2c84e434243956f6",
"type": "tabs", "type": "tabs",
"children": [ "children": [
{ {
"id": "0565fd67a6951906", "id": "a3da3cbd7273dcb3",
"type": "leaf",
"state": {
"type": "image",
"state": {
"file": "TERCERO/ATR1/images/Pasted image 20241211115747.png"
},
"icon": "lucide-image",
"title": "Pasted image 20241211115747"
}
},
{
"id": "6fd893cabd53f492",
"type": "leaf", "type": "leaf",
"state": { "state": {
"type": "markdown", "type": "markdown",
"state": { "state": {
"file": "conflict-files-obsidian-git.md", "file": "TERCERO/DAD/Teoria_2425.md",
"mode": "source", "mode": "source",
"source": false "source": false
}, },
"icon": "lucide-file", "icon": "lucide-file",
"title": "conflict-files-obsidian-git" "title": "Teoria_2425"
} }
} }
], ]
"currentTab": 1
} }
], ],
"direction": "vertical" "direction": "vertical"
@@ -53,7 +40,8 @@
"state": { "state": {
"type": "file-explorer", "type": "file-explorer",
"state": { "state": {
"sortOrder": "alphabetical" "sortOrder": "alphabetical",
"autoReveal": false
}, },
"icon": "lucide-folder-closed", "icon": "lucide-folder-closed",
"title": "Files" "title": "Files"
@@ -187,26 +175,35 @@
"obsidian-git:Open Git source control": false "obsidian-git:Open Git source control": false
} }
}, },
"active": "6fd893cabd53f492", "active": "a3da3cbd7273dcb3",
"lastOpenFiles": [ "lastOpenFiles": [
"TERCERO/ATR1/images/Pasted image 20241211115747.png", "Pasted image 20250203115240.png",
"Pasted image 20250203115222.png",
"Pasted image 20250203115134.png",
"Pasted image 20250203114652.png",
"TERCERO/DAD/Presentación 24-25.md",
"TERCERO/DAD/Teoria_2425.md",
"TERCERO/ATR2/Teoria_2425.md",
"TERCERO/ATR2",
"Untitled",
"conflict-files-obsidian-git.md", "conflict-files-obsidian-git.md",
"TERCERO/DAD",
"TERCERO/PI/Presentación 24-25.md",
"TERCERO/SETR1/Presentación 24-25.md",
"TERCERO/SETR1",
"TERCERO/PI",
"TERCERO/ATR1/images/Pasted image 20241211115747.png",
"TERCERO/SPD/images/arriba.png", "TERCERO/SPD/images/arriba.png",
"TERCERO/SPD/images/abajo.png", "TERCERO/SPD/images/abajo.png",
"TERCERO/SPD/images/Pasted image 20241209194450.png", "TERCERO/SPD/images/Pasted image 20241209194450.png",
"TERCERO/SPD/images/Pasted image 20241209194420.png", "TERCERO/SPD/images/Pasted image 20241209194420.png",
"TERCERO/SPD/images/Pasted image 20241209181348.png", "TERCERO/SPD/images/Pasted image 20241209181348.png",
"TERCERO/SPD/images/Pasted image 20241209180114.png", "TERCERO/SPD/images/Pasted image 20241209180114.png",
"TERCERO/SPD/images/Pasted image 20241209175932.png",
"TERCERO/SPD/images/Imagen de WhatsApp 2024-12-09 a las 20.00.56_ae187147.jpg",
"TERCERO/SPD/images/Imagen de WhatsApp 2024-12-09 a las 19.58.16_359536b7.jpg",
"TERCERO/SPD/images/Imagen de WhatsApp 2024-12-09 a las 19.56.10_a7e685e5.jpg",
"TERCERO/ATR1/Teoría_2425.md", "TERCERO/ATR1/Teoría_2425.md",
"SEGUNDO/RC/Teoría_2324.md", "SEGUNDO/RC/Teoría_2324.md",
"TERCERO/IA/Teoría_2425.md", "TERCERO/IA/Teoría_2425.md",
"TERCERO/SPD/Teoría_2425.md", "TERCERO/SPD/Teoría_2425.md",
"TERCERO/SS/SS 24-25.md", "TERCERO/SS/SS 24-25.md",
"Untitled.md",
"TERCERO/ATR1/Resolución 1 Parcial ATR1.md", "TERCERO/ATR1/Resolución 1 Parcial ATR1.md",
"TERCERO/ATR1/Ejercicios.md", "TERCERO/ATR1/Ejercicios.md",
"TERCERO/SPD/P4_SPD.md", "TERCERO/SPD/P4_SPD.md",
@@ -221,20 +218,11 @@
"TERCERO/ATR1/images", "TERCERO/ATR1/images",
"TERCERO/ATR1/Welcome.md", "TERCERO/ATR1/Welcome.md",
"SEGUNDO/ADDA/MemoriaPI4_SMT4497.docx", "SEGUNDO/ADDA/MemoriaPI4_SMT4497.docx",
"SEGUNDO/ADDA/PI4_SMT4497.zip",
"SEGUNDO/ADDA/MemoriaPI5_SMT4497.pdf",
"SEGUNDO/ADDA/ADDA 23-24.md", "SEGUNDO/ADDA/ADDA 23-24.md",
"SEGUNDO/ADDA/MODELOS.md", "SEGUNDO/ADDA/MODELOS.md",
"SEGUNDO/ADDA/ADDA 15-05.md", "SEGUNDO/ADDA/ADDA 15-05.md",
"SEGUNDO/ADDA/ADDA 15-03.md", "SEGUNDO/ADDA/ADDA 15-03.md",
"SEGUNDO/ADDA/ADDA 13-03.md", "SEGUNDO/ADDA/ADDA 13-03.md",
"SEGUNDO/AC/Teoría_2324.md",
"TERCERO/IA",
"TERCERO/SS",
"TERCERO/SPD",
"SEGUNDO/MD/Apuntes Sage.md",
"SEGUNDO/RC/Untitled.md",
"SEGUNDO/TC/Teoría_2324.md",
"SEGUNDO/SO/Sin título.canvas" "SEGUNDO/SO/Sin título.canvas"
] ]
} }

Binary file not shown.

After

Width:  |  Height:  |  Size: 344 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 168 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 330 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 268 KiB

View File

@@ -0,0 +1,47 @@
# <mark style="background: #FFF3A3A6;">TEMA 1: Nivel de Red</mark>
El protocolo IP no ofrece un servicio orientado a la conexión (es no fiable). Emplea el servicio de entrega de R_PDU empleado por el nivel de enlace (utiliza servicio de su nivel inferior), permitiendo intercambiar información entre hosts o routers y dispositivos que implementen como mucho N.E.D.
Establece las herramientas necesarias para **enrutar**, es decir, definir el camino a seguir por los datos de extremo a extremo.
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
### <mark style="background: #FFB86CA6;">Esquema de direccionamiento</mark>
Todo dispositivo en una red debe poseer una dirección IP para poder transmitir datos usando TCP/IP. Hay dos versiones de IP: IPv4 (32b) e IPv6 (128b). Las direcciones se pueden configurar de dos formas:
- **Estática:** El usuario configura la IP en el host suministrada por el administrador de la red.
- **Dinámica:** Se asigna automáticamente una IP al host mediante DHCP.
## <mark style="background: #ADCCFFA6;">2. Configuración dinámica de direcciones</mark>
### <mark style="background: #FFB86CA6;">DHCP</mark>
Hay varias formas de asignación dinámica de direcciones IP:
- **Asignación automática:**
#### <mark style="background: #D2B3FFA6;">Ciclo básico</mark>
DHCP tiene un ciclo de mensajes básico tal que:
- **DHCP DISCOVER:** intenta encontrar un servidor DHCP
Se envía un paquete IP con IP origen 0.0.0.0 y destino 255.255.255.255 (broadcast).
- **DHCP OFFER:** el/los servidores DHCP ofrecen una dirección IP
El servidor DHCP, si lo hay, envía un paquete IP con IP origen su propia IP y destino la de broadcast
- **DHCP REQUEST:** el cliente pide ciertos parámetros
Se envía un paquete al servidor DHCP con IP origen 0.0.0.0 y destino 255.255.255.255, aunque la IP está "pre-asignada" todavía no se le ha concedido al host dicha IP.
- **DHCP ACK:** ACK de confirmación desde el servidor
El servidor DHCP envía un ACK en un paquete IP con IP origen la suya y destino la de broadcast.
Tras completar el ciclo básico el cliente envía una petición ARP llamada **ARP Gratuito** para ver si cualquier otro host tiene la IP que se le ha asignado. Si no obtiene respuesta, se queda con esa IP. Si la obtiene vuelve a solicitar otra.
#### <mark style="background: #D2B3FFA6;">Formato de mensajes</mark>
Los mensajes DHCP tienen un formato específico:
- Los primeros 4 Bytes se denominan _magic cookie_.
- Cada transacción (petición/respuesta) tiene un id.
## <mark style="background: #ADCCFFA6;">3. Control de errores</mark>
IP no implementa un control de errores, así que en caso de que se produzca un error existen protocolos que se "montan" sobre IP para este propósito.
### <mark style="background: #FFB86CA6;">ICMP (Internet Control Message Protocol)</mark>
Es usado por hosts y routers para comunicar información a nivel de red (informe de errores o avisos). Se encapsulan en datagramas IP, por lo que los dispositivos deben ser de hasta nivel 3.
### Formato de mensajes
- **Type:** Indica el tipo de mensaje ICMP
- **Code.** Indica el subtipo de mensaje
- **Checksum:** Para detectar mensajes corruptos
| Tipo | Código | Descripción |
| ---- | ------ | ----------------------- |
| 0 | 0 | Respuesta de eco (ping) |
| 3 | 0 | Red inalcanzable |
| 3 | 1 | Host inalcanzable |
| 3 | 2 | Protocolo inalcanzable |
| 3 | 3 | Puerto inalcanzable |
| 5 | 0 | Redireccionamiento |
| 8 | 0 | Petición de eco (ping) |
| 11 | 0 | TTL excedido |

View File

@@ -0,0 +1,16 @@
semanas del 10 feb, 24 feb y 10 mar **TEORIA** martes y jueves 12:40 - 14:30
ESP32 NodeMCU
sensores: dht11, mqX,
actuadores: relé, led, actuadores lineales
entregables:
- 0.10 * L02
- 0.20 * L03
- 0.25 * L04
- 0.25 * L05
- 0.15 * L06
- 0.05 * L07
pruebas de evaluación:
- dos tipos test (24 marzo y 15 mayo) APTO/NO APTO

View File

@@ -0,0 +1,83 @@
# <mark style="background: #FFF3A3A6;">TEMA 1: Introducción a los sistemas distribuidos</mark>
El paradigma clásico cliente-servidor es lo que se llama centralizado. Un ejemplo de arquitectura distribuida sería una red P2P (como torrent). Y por último un ejemplo de red descentralizada sería una red como la red Tor.
## <mark style="background: #ADCCFFA6;">1. Introducción a los SSDD</mark>
### <mark style="background: #FFB86CA6;">Qué es un sistema distribuido</mark>
Un sistema distribuido es un conjunto de computadores débilmente acoplados (independientes) interconectados a través de una red que colaboran para realizar una tarea. Los orígenes se remontan a los años 80:
- **Principios de los 80:** Los computadores son máquinas costosas y muy grandes. Sistemas operativos multiusuario de tiempo compartido.
- **A partir de los años 80:** Auge de los computadores personales. Bajo coste. Avances tecnológicos continuos. SO monousuario.
- **A partir de los años 90:** Aparecen las redes de computadores de alta velocidad (LAN y WAN).
### <mark style="background: #FFB86CA6;">Propiedades de los sistemas distribuidos</mark>
- **Concurrencia de los componentes:** no se habla ya de concurrencia a nivel de componente del computador, si no de los distintos computadores que componen el sistema.
- **Carencia de un reloj global:** no existe un reloj que sincronice todos los computadores, sino un coreógrafo que se dedica a hacerlo.
- **Fallos independientes de los componentes:** si falla una máquina se balancea la carga a otras máquinas.
- **Uso de un sistema de comunicación:** WAN, LAN, etc.
- **Ausencia de memoria común:** entendiendo como memoria, la física (RAM, HD). Sin embargo, puede y hay BD compartida.
- **Sincronización del trabajo**
- **Ausencia de un estado global**
- **Comunicación a través de mensajes**
### <mark style="background: #FFB86CA6;">Ejemplos de sistemas distribuidos</mark>
- **Internet**
- **Intranet**
- **Computación móvil y ubicua:** computación que se puede llevar a cabo en cualquier lugar
- **Redes P2P**
- **Grid computing:** paralelizar el problema a resolver con varios equipos para reducir el tiempo de resolución. De ahí viene el nombre de "grid" es una cuadrícula de equipos en paralelo.
- **Redes de sensores**
- **Red bancaria**
- **Servidor FTP**
- **BD distribuidas**
## <mark style="background: #ADCCFFA6;">2. Características de los SSDD</mark>
El principal objetivo de un SD es que el sistema se presente a los usuarios como un único computador monoprocesador virtual. Para ello se persiguen los siguientes conceptos:
| Transparencia | Descripcion |
| -------------- | -------------------------------------------------------------------------------- |
| Acceso | Diferencias en la representación de los datos y como acceder a los recursos |
| Localización | Dónde se encuentra un recurso |
| Migración | Que un recurso pueda moverse de un lugar a otro |
| Relocalización | Que un recurso pueda moverse de un lugar a otro mientras está en uso |
| Replicación | Que puedan existir réplicas de un recurso |
| Concurrencia | Que un recurso pueda ser compartido por varios usuarios |
| Resiliencia | Permitir la recuperación de un recurso en caso de fallos sin que se vea afectado |
| Persistencia | Que un recurso pueda estar en memoria o en disco |
### <mark style="background: #FFB86CA6;">Seguridad en SSDD</mark>
En un sistema distribuido la información se transmite entre los diferentes nodos del mismo mediante paso de mensajes. Hay varios requisitos para garantizar la seguridad:
- El emisor debería saber que su mensaje se ha recibido.
- El receptor de un mensaje debería saber que el que le ha enviado el mensaje es el emisor adecuado.
- Tanto el emisor como el receptor deberían tener garantías de que los mensajes no son observados ni alterados durante la transmisión (no hay un ataque MITM).
### <mark style="background: #FFB86CA6;">Rendimiento en SSDD</mark>
La existencia de más recursos debería permitir que las apps se ejecuten más rápido en un SD que en uno centralizado. Sin embargo, hay algunos problemas:
- Las apps tienen que ser paralelizadas
- Minimizar el tráfico de red
- Equilibrio de carga
- Conseguir que un SD sea transparente, flexible y fiable
<div class="nota"><h1>Heterogeneidad</h1><p>Un SD se puede componer de conjuntos de computadores que pueden difrerir tanto en HW como en SW, esto implica que pueda haber incompatibilidades:</p><ul><li>Los CPUs y lenguajes no usan la misma representación de los datos</li><li>Gran diversidad de protocolos</li></ul></div>
## <mark style="background: #ADCCFFA6;">3. Protocolos</mark>
- **Servicios de red:** capa de servicios estándar en internet: HTTP, DNS, FTP, SMTP
- **Servicios web:** conjunto de servicios montados sobre HTTP: motores de búsqueda, servicios de directorio, cambio de moneda, SMS. Utilizan SOAP y XML.
- **Apps de red:** aplicaciones específicas desarrolladas por usuarios finales. Utilizan middlewares para la comunicación.
## <mark style="background: #ADCCFFA6;">4. Tipos de sistemas</mark>
### <mark style="background: #FFB86CA6;">Computación en clúster</mark>
Conjunto de computadores similares conectados a través de una red LAN de alta velocidad. Se usa para computación en paralelo usualmente. Cada clúster es un conjunto de nodos "slave" monitoreados por los nodos "master".
### <mark style="background: #FFB86CA6;">Computación en red</mark>
Nodos con marcadas diferencias de hardware y tecnología de red.
### <mark style="background: #FFB86CA6;">Computación en la nube</mark>
Recursos virtualizados alojados en el centro de datos del proveedor. Para el usuario, está "alquilando su propia máquina", sin embargo, seguramente sea compartida con otros usuarios. Son bastante escalables ya que permiten configurarse dinámicamente.
#### <mark style="background: #D2B3FFA6;">Modelos de computación en la nube</mark>
![[Pasted image 20250203114652.png]]
### <mark style="background: #FFB86CA6;">Plataformas de computación en la nube</mark>
#### <mark style="background: #D2B3FFA6;">Amazon Web Services (AWS)</mark>
![[Pasted image 20250203115134.png]]
#### <mark style="background: #D2B3FFA6;">Google Cloud Platform (GCP)</mark>
![[Pasted image 20250203115222.png]]
#### <mark style="background: #D2B3FFA6;">Microsoft Azure</mark>
![[Pasted image 20250203115240.png]]
## <mark style="background: #ADCCFFA6;">5. Problemas</mark>
- **Compatibilidad de tipos de datos:** distintos SO que tienen distintos tipos de datos que no siempre son compatibles entre sí.
- **Fallos del servido:** debido a que los componentes pueden ser remotos, un fallo de cualquiera puede hacer que toda la app falle.
- **Fallos del cliente:** el servidor debe saber como responder a fallos del cliente.
- **Reintento de llamadas:** si se hace una llamada a un método en un servidor para generar una orden de compra muy grande, y el servidor responde, pero se pierde la respuesta por un fallo de red, no es muy eficiente volver a enviar la orden de compra.
- **Seguridad:** autenticar a los usuarios, cifrar la información que viaja por la red, evitar DDoS, etc.
- **Sincronización de la hora:** para que no haya incoherencia con la hora real.
- **Formato de los datos**
- **Disponibilidad de los servidores**
- **Acceso a los sistemas de forma remota**
- **Posibilidad de ver los datos por muchas personas**

View File

@@ -0,0 +1,12 @@
Parciales: semana 7/8 y 22 mayo
Prueba de laboratorio: 14/15/16 mayo -> **TODAS LAS PRÁCTICAS OBLIGATORIAS**
Teoría 80% / Laboratorio 20% -> **MÍN. UN 5 EN LOS DOS**
<strong><span style="color:red;">Hack4Change (concurso de proyectos):</span></strong>
- 17-21 feb. INSCRIPCIÓN
- 20 abr. PRESENTACIÓN
- 29 abr. FASE FINAL
- Defensa del trabajo
- Exposición
- 10-20% de la nota

View File

@@ -0,0 +1,7 @@
Lab f0.32
Teoría: 22 mayo
Entrega memorias: 1 junio máx.
Nota final: $0.4 * \text{Lab} + 0.5 * \text{Teoria} + 0.1 * \text{Idea innovadora}$
mín 4.5