vault backup: 2025-03-02 03:02:52
This commit is contained in:
Jose
@@ -1,4 +1,4 @@
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Nivel de Red</mark>
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 1: Nivel de Red (DHCP-NA(P)T-ICMP)</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.
|
||||
@@ -51,3 +51,28 @@ Hay dos alternativas:
|
||||
- **Dinámica:** El router NAT asignará de forma temporal las IPs públicas cuando haya necesidad de "saltar" a internet.
|
||||
- El router tiene un rango de IPs asignables y además una tabla para guardar dichas asignaciones de IPs.
|
||||
- **Estática:** Se configuran las asignaciones de forma permanente por el administrador de la red.
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Nivel de Red (Routing)</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Introducción</mark>
|
||||
Para que el datagrama se entregue con éxito se debe cumplir:
|
||||
- El prefijo de dirección destino debe corresponder a una sola red
|
||||
- Los routers y hosts que tienen un prefijo de red común deben ser capaz de intercambiar datos sin ayuda de un router
|
||||
- Cada red (a nivel 2) debe estar conectada al menos con otra red mediante un router
|
||||
Un nodo (router o host) tiene que tener una tabla de enrutamiento. Suele tener los campos **Red**, **Próximo Salto**, **Interfaz**.
|
||||
![[Pasted image 20250225091113.png]]
|
||||
En Windows, la **Métrica** es el "coste" que tiene esa ruta si se escoge. Se puede valorar en términos de velocidad, TTL o _delay_ temporal.
|
||||
## <mark style="background: #ADCCFFA6;">2. Reenvío / Enrutamiento</mark>
|
||||
Hay varios pasos en el reenvío:
|
||||
1. Validar cabecera
|
||||
2. Procesar opciones
|
||||
3. Analizar destino
|
||||
4. Buscar destino en la tabla de enrutamiento
|
||||
5. Decrementar TTL
|
||||
6. Fragmentar
|
||||
7. Calcular checksum
|
||||
8. Reenviar al PS
|
||||
9. Enviar ICMP
|
||||
## <mark style="background: #ADCCFFA6;">3. Información global</mark>
|
||||
## <mark style="background: #ADCCFFA6;">4. Información descentralizada</mark>
|
||||
## <mark style="background: #ADCCFFA6;">5. Enrutamiento estático</mark>
|
||||
## <mark style="background: #ADCCFFA6;">6. Enrutamiento dinámico</mark>
|
||||
## <mark style="background: #ADCCFFA6;">7. RIP</mark>
|
||||
|
||||
@@ -153,4 +153,66 @@ Es un sistema de eventos distribuidos:
|
||||
## <mark style="background: #ADCCFFA6;">1. Sockets</mark>
|
||||
Un **socket** es un método para comunicar programas entre sí mediante el paradigma C-S. Un socket también es una dirección en internet tipo IP:puerto.
|
||||
## <mark style="background: #ADCCFFA6;">2. Servlets</mark>
|
||||
Programa Java que se ejecuta en un servidor Web y construye o sirve páginas web. De esta forma se pueden construir páginas dinámicas, basadas en diferentes fuentes variables.
|
||||
Programa Java que se ejecuta en un servidor Web y construye o sirve páginas web. De esta forma se pueden construir páginas dinámicas, basadas en diferentes fuentes variables.
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 4: Diseño de servidores y escalabilidad</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Problema de los servidores de apps tradicionales</mark>
|
||||
- Un thread controla una tarea
|
||||
- Los threads esperan a que finalice la tarea que está ejecutando mientras que los demás están en queue
|
||||
- No escalable
|
||||
- Muchos threads probablemente
|
||||
- Sistema de concurrencia muy complejo
|
||||
## <mark style="background: #ADCCFFA6;">2. Vert.X</mark>
|
||||
- Framework políglota de propósito general sobre la JVM.
|
||||
- APIs asíncronas, event-driven, non-blocking.
|
||||
- MUY escalable
|
||||
![[Pasted image 20250227131516.png|450]]
|
||||
<small>Ejemplo verticle</small>
|
||||
|
||||
Con Vert.X se puede hacer:
|
||||
- TCP/SSL server
|
||||
- HTTP/S server
|
||||
- Websockets
|
||||
- Acceso distribuido al EB (Event Bus)
|
||||
- Intercambio de Maps/Sets
|
||||
- Logging
|
||||
## <mark style="background: #ADCCFFA6;">3. Arquitectura</mark>
|
||||
### <mark style="background: #FFB86CA6;">Estructura</mark>
|
||||
- Vert.X Core
|
||||
- Verticle
|
||||
- Event bus
|
||||
- Messages
|
||||
- Handlers
|
||||
- Modules
|
||||
### <mark style="background: #FFB86CA6;">Vert.X Core</mark>
|
||||
- Cada verticle una instancia de Vert.X
|
||||
- Cada instancia de Vert.X en una instancia propia de la JVM
|
||||
- Un event loop que sirve conexiones de manera asíncrona
|
||||
- La mayor parte del trabajo real se lleva a cabo en un pool de threads en segundo plano
|
||||
- Se emplean todos los cores disponibles como threads en segundo plano
|
||||
### <mark style="background: #FFB86CA6;">Verticle</mark>
|
||||
- Cada Verticle está aislado con diferentes class loaders
|
||||
- Un Verticle nunca es ejecutado por más de un thread concurrentemente
|
||||
- No existen deadlocks, dependencias, etc. El desarrollo se hace pensando en single thread.
|
||||
#### <mark style="background: #D2B3FFA6;">Standard Verticles</mark>
|
||||
Se ejecutan en el mismo thread que el event loop.
|
||||
#### <mark style="background: #D2B3FFA6;">Worker Verticles</mark>
|
||||
Están diseñados para tareas bloqueantes. Se ejecutan en un thread distinto que **SÍ** se puede bloquear.
|
||||
#### <mark style="background: #D2B3FFA6;">Multithread Worker Verticles</mark>
|
||||
Se ejecutan de manera concurrente en varios threads (no se suele usar).
|
||||
### <mark style="background: #FFB86CA6;">Event Bus</mark>
|
||||
- Pilar central de la estructura Vert.X
|
||||
- Permite que se comuniquen los Verticles
|
||||
- No depende del lenguaje
|
||||
- Independiente del equipo en el que se ejecute
|
||||
- Válido para C y S
|
||||
El event bus soporta varios mecanismos de comunicación:
|
||||
- Publish/Subscribe
|
||||
- P2P
|
||||
- Request/Response
|
||||
### <mark style="background: #FFB86CA6;">Messages</mark>
|
||||
- **Addressing:** se envian a una direccion. String con el nombre del verticle + destinatario.
|
||||
- **Handlers:** reciben los mensajes. Se deben registrar con una dirección y pueden registrarse con varias.
|
||||
- **Publish/Subscribe:** los mensajes se publican a una dirección. Todos los handlers subscritos recibirán el mensaje
|
||||
- **P2P y Req/Res:** envío de mensajes a un único handler. El receptor puede responder.
|
||||
### <mark style="background: #FFB86CA6;">Modules</mark>
|
||||
Mongo DB, Redis, MySQL, SMTP, JDBC, Jersey, Promises, Guice, Spring, Vertigo, Metrics, Facebook, Yoke, Stomp, NoDyn, GCM, SocketIO, Sessions, Via, RxJava
|
||||
|
||||
@@ -30,3 +30,82 @@ Hay dos tipos de direccionamiento:
|
||||
- **Ventajas:**
|
||||
- Atención inmediata
|
||||
- El CPU puede hacer otras cosas mientras el dispositivo E/S está ocupado
|
||||
|
||||
# <mark style="background: #FFF3A3A6;">TEMA 2: Buses locales normalizados</mark>
|
||||
## <mark style="background: #ADCCFFA6;">1. Concepto de bus normalizado</mark>
|
||||
**Bus:** conjunto de líneas eléctricas sobre la PCB. Es un medio compartido.
|
||||
### <mark style="background: #FFB86CA6;">Ejemplo de bus y sus líneas</mark>
|
||||
Un ejemplo de bus sería el **Bus de Control** con las líneas típicas:
|
||||
- Memory write
|
||||
- Memory read
|
||||
- I/O Write
|
||||
- I/O Read
|
||||
- Transfer ACK
|
||||
- Bus Request
|
||||
- Bus Grant
|
||||
- Int Request
|
||||
- Int ACK
|
||||
- Clock
|
||||
- Reset
|
||||
### <mark style="background: #FFB86CA6;">Procesos de transferencia</mark>
|
||||
Por ejemplo para la escritura E/S:
|
||||
1. El módulo de E/S que quiere iniciar la transferencia solicita el uso del bus (**Bus Request**)
|
||||
2. El arbitrador concede el bus (**Bus Grant**)
|
||||
3. Sitúa en el bus de direcciones (AB) la dirección o puerto E/S donde quiere transferir el dato
|
||||
4. Sitúa el dato a transferir en el bus de datos (DB)
|
||||
5. Activa la línea de **I/O Write** del bus de control
|
||||
6. El destinatario ha recibido el dato (**Transfer ACK**)
|
||||
7. Deja libre el bus para su uso
|
||||
<div class="nota"><h4>NOTACIÓN</h4><ul><li><strong>Bus Master:</strong>Módulo que inicia la transmisión</li><li><strong>Bus Slave:</strong>Módulo direccionado por el Bus Master</li><li><strong>Arbitrador:</strong>circuito especial que recoge las peticiones para tomar el control del bus y decide quién lo toma</li></ul></div>
|
||||
### <mark style="background: #FFB86CA6;">Arquitectura de un PC actual</mark>
|
||||
![[Pasted image 20250225110824.png]]
|
||||
## <mark style="background: #ADCCFFA6;">2. Métodos de conexión de un dispositivo al bus local</mark>
|
||||
### <mark style="background: #FFB86CA6;">Conexión directa</mark>
|
||||
**Restricciones:**
|
||||
- Depende del CPU
|
||||
- Sólo lo puede usar un dispositivo local para evitar problemas de impedancia por extra carga
|
||||
- Costosa, debido a la alta frecuencia
|
||||
- No permite transferencias de datos entre CPU y otros dispositivos mientras se usa este bus con otros periféricos
|
||||
**Ejemplo:** VLB tipo A
|
||||
![[Pasted image 20250225111612.png|300]]
|
||||
### <mark style="background: #FFB86CA6;">Conexión mediante buffer</mark>
|
||||
**Mejoras:**
|
||||
- Sólo presenta una impedancia. Usualmente hasta 3 dispositivos
|
||||
**Restricciones:**
|
||||
- En esencia, con buffer y el local son un único bus: cualquier transferencia iniciada por CPU alcanzará el bus local con buffer. **NO** es posible la utilización simultánea.
|
||||
**Ejemplo:** VLB tipo B
|
||||
![[Pasted image 20250225111801.png|300]]
|
||||
### <mark style="background: #FFB86CA6;">Conexión con filosofía workstation</mark>
|
||||
**Mejoras:**
|
||||
- Introducción de caché L2 unida a un puente para adaptar las velocidades de transferencia entre bus local del CPU y el de E/S.
|
||||
- Independencia del procesador que implementa la CPU.
|
||||
**Ejemplo:** PCI
|
||||
![[Pasted image 20250225111938.png|300]]
|
||||
## <mark style="background: #ADCCFFA6;">3. PnP</mark>
|
||||
### <mark style="background: #FFB86CA6;">El problema</mark>
|
||||
- Hay un número limitado de IRQs, canales DMA, puertos de E/S y regiones de memoria E/S
|
||||
- Algunas IRQs y direcciones están muy estandarizadas
|
||||
- No hay automatización de las tareas de configuración de periféricos
|
||||
### <mark style="background: #FFB86CA6;">Solución PnP</mark>
|
||||
1. El programa de configuración PnP encuentra todos los dispositivos que soportan PnP y pregunta a cada uno qué recursos del bus necesitan.
|
||||
2. Decide qué recursos puede adjudicar.
|
||||
3. Establece un criterio mediante el cual adjudicar recursos del bus.
|
||||
## <mark style="background: #ADCCFFA6;">4. Bus SPI</mark>
|
||||
- El bus SPI (Serial Peripheral Interface) fue desarrollado por Motorola en 1980. Sus ventajas respecto a otros sistemas han hecho que se convierta en un estándar.
|
||||
- El bus SPI tiene arquitectura Master-Slave. El dispositivo maestro puede iniciar la comunicación con uno o varios esclavos y envía (Tx) o recibe (Rx) datos de ellos. Los esclavos ni pueden iniciar comunicación ni comunicarse entre ellos.
|
||||
- Hay una línea para transmisión (Tx) y otra para recepción (Rx) por lo que la comunicación es Full Dúplex.
|
||||
- Es síncrono, el dispositivo maestro proporciona el CLK.
|
||||
![[Pasted image 20250225112945.png|400]]
|
||||
- **MOSI (Master-Out, Slave-In):** para la comunicación maestro a esclavo.
|
||||
- **MISO (Master-In, Slave-Out):** para la comunicación esclavo a maestro.
|
||||
- **SCK (Clock):** señal de CLK del maestro.
|
||||
|
||||
![[Pasted image 20250225113139.png|600]]
|
||||
## <mark style="background: #ADCCFFA6;">5. Bus I2C</mark>
|
||||
- El estándar I2C (Inter-Integrated Circuit) requiere únicamente dos cables para su funcionamiento, uno para CLK y otro para el envío de datos (SDA). El funcionamiento es más complejo así como su circuitería.
|
||||
![[Pasted image 20250225113929.png]]
|
||||
- En el bus cada dispositivo tiene una dirección, que se emplea para acceder a ellos de forma individual. Esta dirección puede ser fijada por hardware o software.
|
||||
- En general, cada dispositivo conectado al bus debe tener dirección única. Se podría cambiar la dirección o implementar un segundo bus.
|
||||
- Este bus tiene una arquitectura maestro-esclavo. Es posible que haya más de un maestro pero **SÓLO** un maestro a la vez.
|
||||
- Es síncrono, el maestro proporciona CLK.
|
||||
- Tiene resistencias de pull-up a $V_{CC}$ .
|
||||
@@ -114,8 +114,57 @@ int main()
|
||||
</div>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">2. Intel 8051</mark>
|
||||
![[Pasted image 20250220110642.png|500]]
|
||||
![[Pasted image 20250220110558.png|400]]
|
||||
![[Pasted image 20250220110616.png]]
|
||||
### <mark style="background: #FFB86CA6;">Características</mark>
|
||||
- Punteros de datos y de pila de distinto tamaño que PC (Program Counter) o IP (Instruction Pointer) porque es Harvard.
|
||||
- Complejidad de mapa de memoria.
|
||||
- Juego de instrucciones limitado.
|
||||
- La pila está en memoria de datos interna y limitada a 256B por ser el SP de 8b.
|
||||
- Instrucciones de acceso memoria-memoria sin pasar por un acc.
|
||||
- Acumuladores accesibles por dir. directo.
|
||||
- Necesario acceder a memoria de código para datos constantes -> `movc`.
|
||||
### <mark style="background: #FFB86CA6;">Mapa de memoria</mark>
|
||||
![[Pasted image 20250220114954.png]]
|
||||
Asignación memoria variables:
|
||||
- DATA: 128B bajos en RAM interna
|
||||
- BDATA: memoria direccionable bit
|
||||
- IDATA: 128B direccionamiento indirecto
|
||||
- PDATA: memoria por bancos
|
||||
- XDATA: memoria datos externa
|
||||
- CODE: memoria de código
|
||||
**Ejemplos:**
|
||||
```C
|
||||
code unsigned char var1;
|
||||
|
||||
bdata char var2;
|
||||
sbit var2bit2 = var2^2;
|
||||
var2bit2 = 1;
|
||||
```
|
||||
## <mark style="background: #ADCCFFA6;">3. Cortex M</mark>
|
||||
### <mark style="background: #FFB86CA6;">Introducción</mark>
|
||||
- Arquitectura ARM (Advanced RISC Machines)
|
||||
- Empezó en 1983 de parte de Acorn Computers Ltd.
|
||||
- Originalmente para PCs (arquitectura Von Neumann)
|
||||
- RISC -> instrucciones de 4B. Los más recientes traen un conjunto de instrucciones de 16 bits adicional, llamado **Thumb**.
|
||||
### <mark style="background: #FFB86CA6;">Buses</mark>
|
||||
#### <mark style="background: #D2B3FFA6;">Tipos de buses</mark>
|
||||
- **AHB (Advanced High performance Bus):** memoria, periféricos rápidos...
|
||||
- **APB (Advanced Peripheral Bus):** periféricos generales
|
||||
- **PPB (Private Peripheral Bus):** acceso al debugger e interrupciones
|
||||
![[Pasted image 20250227115420.png|600]]
|
||||
#### <mark style="background: #D2B3FFA6;">Buses internos</mark>
|
||||
- **Buses CORE:**
|
||||
- **Icode bus AHB:** acceso a la memoria de código (ROM, Flash...) alineados de 32 en 32 bits (al usar instrucciones de 16 bits se toman instrucciones de 2 en 2).
|
||||
- **Dcode bus AHB:** acceso a datos almacenados en memoria de código sin alineamiento.
|
||||
- **System bus AHB:** acceso R/W a la zona de memoria SRAM (interna, externa, extendida), periféricos y controladores rápidos (DMA)
|
||||
- **Internal PPB:** debugger, interrupciones, etc
|
||||
### <mark style="background: #FFB86CA6;">Mapa de memoria</mark>
|
||||
![[Pasted image 20250227120032.png|500]]
|
||||
|
||||
### <mark style="background: #FFB86CA6;">Registros</mark>
|
||||
### <mark style="background: #FFB86CA6;">Set de instrucciones</mark>
|
||||
|
||||
## <mark style="background: #ADCCFFA6;">4. Manipulación de bits</mark>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user