José M. Piquer
2 hrs
Con Apuntes
ATM permite switching de celdas a alta velocidad, sobre fibra óptica, entregando anchos de banda cercanos al Gbit/s. Sin embargo, también se puede hoy multiplexar una fibra en frecuencia, obteniendo miles de Gbit/s en una sola fibra. Compare ambas tecnologías, cuando lo que requiero es un backbone para correr IP. Discuta los pro y los contra y decida cuál usaría usted (a precio equivalente).
La principal diferencia entre ambas tecnologías es que ATM funciona en
una red compuesta por switches y fibras, lo que permite conmutar celdas en
la red. La multiplexión en frecuencia sólo tiene sentido en una sola
fibra, por lo que la funcionalidad la obtengo solamente entre dos puntos
de la red, típicamente routers. La respuesta, entonces dependerá mucho
de la topología de la red que quiero construir.
Un punto interesante es que ATM usa celdas muy pequeñas, generando mucho
overhead para IP. En multiplexión en frecuencia puedo usar un framing mínimo
con paquetes grandes sin problemas. Finalmente, es importante ver que
las dos tecnologías se sitúan a niveles distintos, pudiendo, por ejemplo,
correr ATM en una frecuencia de la fibra.
Por lo tanto, a priori, a precio igual,
parece mejor multiplexión en frecuencia.
Explique la diferencia entre un hub, un repeater, un bridge y un switch ethernet. Argumente en qué momento es recomendable usar un router.
Un hub es un repetidor multi-puertas, por lo que es equivalente a
un repeater. Un bridge rutea a nivel físico, aprendiendo la distribución
de las direcciones ethernet. Un switch evita colisiones entre sus puertas,
normalmente incluye función de bridge.
Un router es recomendable en varias situaciones: a) cuando las redes
a conectar son físicamente distintas, b) cuando son administrativamente
distintas y c) cuando el tráfico aumenta mucho y los broadcasts se vuelven
un problema.
Proponga un método de implementar una red IP sobre líneas telefónicas digitales. La idea es que la interfaz de red es una puerta telefónica digital (alta velocidad, confiable), pero discada. Es decir debemos dar el número de teléfono (dirección física) y establecer una conexión para transmitir los datos a destino. Luego debemos cortar la conexión antes de establecer un nuevo llamado.
Analice los problemas que presenta esto y proponga soluciones.
Debemos ver esto como una sub-red IP, por lo que debemos encapsular los
paquetes IP en algún framing (ppp, hdlc, etc). El único problema es
la resolución de direcciones (ARP), puesto que no tenemos broadcast.
Una solución es tener un archivo en cada máquina con la traducción
IP - número de teléfono. Una mejor es tener un servidor ARP (como en ATM)
con el cual debo conectarme para registrarme y a él le pido las traducciones.
Puedo recordar los números durante algunos minutos, para evitar tener que
conectarme a cada rato.
Cuando llega un paquete IP para un destino en esta red, disco su número de
teléfono y lo envío. La conexión debiera permanecer durante un tiempo
y cortarla al quedar ociosa muchos minutos o al recibir paquetes para otro
destino.
El problema principal es la lentitud en conectar y desconectar las llamadas.
No tenemos conectividad con un equipo dado en Internet. Al hacerle ping, vemos que nuestros paquetes van correctamente ruteados hacia esa máquina, pero las respuestas no me llegan.
Explique cómo puede pasar esto y diseñe una serie de pruebas para determinar donde está el problema.
Pueden existir varios problemas en las rutas, tanto de ida como de
vuelta. Lo mejor es comenzar haciendo un traceroute hacia el destino
y ver hasta donde veo los routers intermedios. El problema debe estar
después del último router que veo. En ese momento, me conviene mirar en cada
una de las redes por las que atraviesa el paquete mientras hago ping.
Así puedo ver si pasa el paquete por allí. Puedo hacer ping desde esa
red hacia mi host, para ver si la ruta de retorno está correcta.
Es importante ver que la ruta de ida puede estar buena (y mis pings llegar
hasta el destino) y la de vuelta mala (así, son las respuestas las que se
pierden).
Explique porqué no es buena idea tener dos sub-redes de la misma red IP sin conexión directa. ¿Qué necesito hacer para que funcione?
Al rutearse fuera de la sub-red, los paquetes son dirigidos a la red completa, sin entender de sub-redes. Por lo tanto, los paquetes para la primera sub-red pueden llegar a la segunda y ahí quedarán en un ciclo. La forma de corregir esto es que todos los routers entre ambas sub-redes conozcan la máscara de la red y tengan rutas específicas para cada una.
Explique porqué TCP no actualiza el RTT estimado cuando recibe ACK's para paquetes retransmitidos.
Es porque no puede distinguir si ese ACK es para el primer paquetes o para la retransmisión. Por lo tanto, no se arriesga a suponer un RTT muy bajo, lo que genera más retransmisiones.
Explique porqué NFS no se puede utilizar en Internet, y sólo funciona en redes locales.
NFS corre sobre UDP con timeouts fijos (constantes). Esto es inusable en Internet, donde las varianzas de los tiempos de ida y vuelta son enormes.
Escriba un proxy UDP que permite que pasen los paquetes a través de un firewall. Escucha conexiones en el port 8000, y al recibir un cliente se conecta a un host y un port que recibe de argumentos:
proxy(char *host, int port);
Al terminar la conexión, debe cerrar los sockets y morir.
La idea general es tener una tabla de sockets hacia el servidor externo, de modo de poder diferenciar para quién es la respuesta. Según por cual socket llega, yo le respondo a otro cliente interno. Por lo tanto, en esa tabla tengo tantos sockets como clientes internos han usado al proxy. No me preocupo de borrar sockets, pero después de un cierto tiempo sin uso, podrían borrarse.
proxy(char *host, int port)
{
s = socket( AF_INET, SOCK_DGRAM, 0 );
if( s < 0 )
{
perror("Create_link (socket)");
return(-1);
}
sin.sin_family = AF_INET;
sin.sin_port = htons(8000);
sin.sin_addr.s_addr = INADDR_ANY;
if( bind(s, (struct sockaddr *)&sin, sizeof sin) < 0 )
{
perror("Create_link(bind)");
return(-1);
}
sout.sin_family = AF_INET;
sout.sin_port = port;
sout.sin_addr.s_addr = gethostbyname(host);
for(;;)
{
select({s,soc_tab[]}, &mask);
if( ISSET(&mask, s) )
{
/* Paquete de la red interna hacia afuera */
len = sizeof(struct sockaddr);
size = recvfrom(s, buf, BUF_SIZE, 0, &saddr, &len);
/* Si no esta en la tabla de clientes, lo agregamos */
i = search(soc_tab, &saddr);
if( i == -1 )
i = add_table(soc_tab, &saddr);
/* en i tenemos el socket para ese cliente */
sendto(i, buf, size, 0, &sout, &len);
}
for(i=0; i < MAX_SOCKS; i++) {
/* Busco un socket cliente con trafico */
if( ISSET(&mask, i) )
{
len = sizeof(struct sockaddr);
size = recvfrom(s, buf, BUF_SIZE, 0, &saddr, &len);
sendto(soc_tab[i].sock, buf, size, 0, soc_tab[i].saddr, &len);
}
}
}
}
Explique porqué TCP no es razonable de usar para enviar multimedia en tiempo real.
Al manejar ventanas y retransmisiones, TCP genera retardos enormes frente a pérdidas. Multimedia en tiempo real no soporta retardos variables, por lo que se requiere evitar retransmitir, por lo tanto, evitar TCP.
CC51C Comunicación de Datos Examen
This document was generated using the LaTeX2HTML translator Version 95 (Thu Jan 19 1995) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -no_navigation -split 0 pautaex.tex.
The translation was initiated by Jo Piquer on Tue Jul 6 09:23:37 CLT 1999