\documentclass[12pt,a4paper]{article}
\usepackage[pdftex]{color}
\usepackage[latin1]{inputenc}
\usepackage[spanish]{babel}
\usepackage{epsfig}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{comment}

%\voffset         -2.0 cm
\hoffset         -1.5 cm
%\textheight      26.0 cm
\textwidth       19.0 cm
\oddsidemargin    0.0 cm
\evensidemargin   0.0 cm

\begin{document}

\thispagestyle{empty}
\pagestyle{empty}

\begin{center}
{\large\textbf{Redes de Computadoras}}\\
Junio de 2008\\
\end{center}
\hrule\bigskip
%\noindent Especifique su \textbf{nombre}, \textbf{carrera} y \textbf{dirección de correo electrónico} en todos los folios entregados.\\
\hrule\bigskip


\begin{enumerate}

% 1
\item {\bf ($1$ punto)} Actualmente la mayor parte del ancho de banda
  de Internet se dedica a las aplicaciones peer-to-peer. Por otra
  parte, la gran mayoría de los enlaces involucrados en el tráfico P2P
  son asimétricos (la tasa de bits de bajada es bastante mayor que
  la tasa de bits de subida). Ante esta situación imaginemos que
  todos los IPS's de Internet deciden, de golpe (y sin coste extra
  para los usuarios ... aunque esto sea irrelevante para resolver este
  ejercicio), duplicar el ancho de banda de descarga, pero manteniendo
  fijos los de subida. ¿Es razonable esperar que el encho de banda de
  Internet dedicado al tráfico P2P también se duplique? Razone.
\begin{verbatim}
%  Los usuarios de la red P2P descargan lo que otros usuarios
%  suben. Si las tasas de subida no aumentan, tampoco lo harán
%  las de bajada. Por tanto, el tráfico P2P en Internet no se
%  duplicará.
\end{verbatim}
  
% 4
\item {\bf ($3$ puntos)} Suponga que ejecuta un analizador de tráfico
  (como pueda ser Wireshark) en un host conectado a Internet. Con él
  obtiene la siguiente traza:
\begin{verbatim}
Instante
de tiempo Protocolo   IP origen      IP destino     Datos sobre el payload
--------- --------- --------------- --------------- ----------------------
        1       DNS 193.147.118.10  193.147.118.1   ¿X.ace.ual.es?
        2       DNS 193.147.118.1   193.147.118.10  X.ace.ual.es = 193.147.118.2
        3      HTTP 193.147.118.10  193.147.118.2   GET / HTTP/1.1
                                                    Host: www.google.es
        4       DNS 193.147.118.2   193.147.118.1   ¿www.google.es?
        5       DNS 193.147.118.1   193.147.118.2   No sé, pregunta a 10.20.30.40
        6       DNS 193.147.118.2    10. 20. 30.40  ¿www.google.es?
        7       DNS  10. 20. 30.40  193.147.118.2   www.google.es = 205.85.129.147

        8      HTTP 193.147.118.2   205. 85.129.147 GET / HTTP/1.1
                                                    Host: www.google.es
        9      HTTP 205. 85.129.147 193.147.118.2   HTTP/1.1 200 OK [Objeto ...]
       10      HTTP 193.147.118.2   193.147.118.10  HTTP/1.1 200 OK [Objeto ...]
\end{verbatim}
Responda a las siguientes preguntas (¡¡¡RAZONE todos los casos!!!):
\begin{enumerate}
\item {\bf ($0.25$ puntos)} ¿Cuál es la dirección IP del host que
  ejecuta el analizador? % 0.25
\begin{verbatim}
%  Podría ser 193.147.118.10, si éste estubiera en el mismo dominio
%  de colisión que 193.147.118.2 y que 193.147.118.1. 
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué servicios hay instalados en el host
  193.147.118.1? % 0.5
\begin{verbatim}
%  Al menos, un servidor de nombres. Esto es así porque recibe una
%  petición DNS en el instante 1 y genera una respuesta DNS en el
%  instante 2.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué servicios hay instalados en el host
  193.147.118.2? % 0.75
\begin{verbatim}
%  Al menos, un servidor proxy Web y un servidor de nombres
%  (probablemente caché). Esto es así porque recibe una petición HTTP
%  en el instante 3 y genera una petición HTTP en el instante 8. Esto
%  sólo lo puede hacer un proxy Web. Como hemos indicado también posee
%  un servicio DNS porque el servidor DNS 193.147.118.1 le indica que
%  él no conoce la IP de www.google.es y que le pregunte a
%  10.20.30.40. Esto sólo puede ocurrir si 193.147.118.2 posee un
%  servidor DNS.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué servicios hay instalados en el host
  193.147.118.10? % 1.0
\begin{verbatim}
%  En principio, ninguno.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué clientes hay instalados en el host
  193.147.118.10? % 1.25
\begin{verbatim}
%  Al menos, un cliente Web y un cliente DNS.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué servicios hay instalados en el host
  10.20.30.40? % 1.5
\begin{verbatim}
%  Al menos, un servidor de nombres.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué servicios hay instalados en el host
  205.85.129.147? % 1.75
\begin{verbatim}
%  Al menos, un servidor Web.
\end{verbatim}
\item {\bf ($0.5$ puntos)} ¿Cómo explica la captura del paquete del
  instante 5? % 2.25
\begin{verbatim}
%  Si 193.147.118.10 ejecuta el analizador, el paquete del instante 5
%  que no tiene como origen ni destino este host sólo podría ser
%  capturado por él si estuviera en el mismo dominio de colisión que
%  193.147.118.2 y 193.147.118.1. La configuración más factible que es
%  que la red local de 193.147.118.10 se haya creado usando un hub.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Qué tipo de consulta DNS entre servidores
  se ha usado: iterativa o recursiva? % 2.5
\begin{verbatim}
%  Es iterativa porque a 193.147.118.2 (el host que recibe la petición
%  DNS en primer lugar) es el que tiene que preguntar a los distintos
%  servidores DNS.
\end{verbatim}
\item {\bf ($0.25$ puntos)} ¿Se puede determinar, a partir de la
  captura mostrada, la dirección IP de la puerta de enlace (gateway)
  del host 193.147.118.10? % 2.75
\begin{verbatim}
%  No. A nivel de la capa de aplicación ningún mensaje suele tener
%  como destino el qateway. Por tanto, es imposible determinarlo.
\end{verbatim}
\item {\bf ($0.25$ puntos)} Suponiendo que la caché DNS de
  193.147.118.1 está inicialmente vacía, ¿qué dominio sirve dicho
  host? % 3
\begin{verbatim}
%  ace.ual.es. Fijarse en el paquete 2.
\end{verbatim}
\end{enumerate}

% 5
\item {\bf ($1$ punto)} ¿Puede un servidor concurrente establecer
  más de una conexión TCP con más de un cliente, simultaneamente,
  usando el mismo puerto (en la parte servidora)? ¿Y si el servidor es
  iterativo? Razone.
\begin{verbatim}
%  Sí, usando TCP el servidor diferencia ambas conexiones a partir del
%  otro punto extremo. Esto es independiente de si el servidor es
%  concurrente o iterativo. Ejemplo: un servidor Web.
%  Nótese sin embargo, que si se trata de un servidor iterativo entonces esta
%  circunstancia nunca se daría porque el servidor sólo mantiene
%  una conexión TCP abierta en un instante de tiempo determinado.
\end{verbatim}

% 6
\item {\bf ($1$ punto)} Los siguientes programas hacen básicamente lo mismo:
\begin{verbatim}
/* Versión en Java */
import java.net.Socket;
import java.net.UnknownHostException;
import java.io.IOException;

public class X {
  public static void main(String[] args) {
    String host = "localhost";
    for (int port = 1; port < 65536; port ++) {
      try {
        Socket s = new Socket(host, port);
        s.close();
        System.out.println(port);
      }
      catch (UnknownHostException e) {
        System.out.println(e.getMessage());
      }
      catch (IOException e) {
      }
    }
  }
}

/* Versión en C */
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <unistd.h>

int main() {
  struct hostent *host_info = gethostbyname("localhost");
  int port;
  for(port=1; port<65536; port++) {
    int socket_descriptor = socket(AF_INET, SOCK_STREAM, 0);
    if (socket_descriptor < 0) {
      fprintf(stderr,"cannot create socket\n");
      exit(1);
    }
    struct sockaddr_in server_address;
    server_address.sin_family = host_info->h_addrtype;
    memcpy((char *) &server_address.sin_addr.s_addr,
      host_info->h_addr_list[0], host_info->h_length);
    server_address.sin_port = htons(port);
    if (connect(socket_descriptor, (struct sockaddr *) &server_address,
        sizeof(server_address)) >= 0) {
      printf("%d\n", port);
    }
    close(socket_descriptor);
  }
  return 0;
}

\end{verbatim}
  ¿Qué información deberían mostrar cuando son ejecutados? Razone su respuesta.
\begin{verbatim}
%  Se muestran los puertos en los que escucha un servidor TCP.
\end{verbatim}
  
% 7
\item {\bf ($1$ punto)} Si el servidor \texttt{smtp.ual.es} sólo
  dejara conectarse desde hosts de la Universidad de Almería, ¿podrían
  los alumnos de la Universidad recibir correo desde
  \texttt{smtp.google.com}? Razone su respuesta.
\begin{verbatim}
%  Sean los alumnos de la universidad de Almería aquellos que reciben
%  correo en smtp.ual.es. En estas circunstancias, si no existiera
%  otro servidor SMTP en el dominio "ual.es" que no tuviera tal
%  restricción y que funcionara como smart host (permitiera reencaminar
%  correos a través de él desde smtp.google.com a smtp.ual.es), sería
%  imposible.
\end{verbatim}

% 8
\item {\bf ($1$ punto)} Un host A envía a un host B un fichero enorme
  usando el TCP. Durante la transmisión no se pierde ningún paquete,
  ni expira ningún temporizador. Por otra parte, sea $R$ la tasa de
  transmisión del enlace que une A con B, medida en bits por segundo
  (bps) y sea $S=10R$ la tasa de generación de datos en A, también
  medida en bps. Suponga que el buffer de recepción de B es lo
  suficientemente grande como para contener el fichero completo, pero
  que el buffer de emisión de A sólo puede almacenar el $1\%$ del
  fichero. ¿Qué factor provocaría que A no transmitiera el fichero
  hasta B, de forma continua, a una tasa constante de $S$ bps? ¿Sería
  el control de flujo del TCP o el control de la congestión? ¿Por qué?
\begin{verbatim}
%  Problema 3.30 del libro de Kurose y Ross.
% 
%  Si en el buffer de recepción de B cabe el fichero completo, el
%  control del flujo del TCP no va a activarse.
% 
%  Si no se pierden ACK's ni expiran temporizadores, el sistema de
%  control de congestión del TCP no va a activarse.
% 
%  Puesto que la tasa de generación de datos S en A es superior a la
%  tasa de transmisión R, los datos se van a transmitir a una tasa
%  (constante o no) que a lo sumo va a ser de R bps. Por tanto, el
%  factor que limita la tasa de transmisión es la capacidad del enlace
%  entre A y B.
% 
%  Nota:
%  Como la tasa de generación de datos es superior a la de transmisión,
%  el buffer en A se llena más rápido que se vacía, y por tanto, siempre
%  va a haber datos dispuestos para ser transmitidos. Si el buffer de
%  emisión de A (aunque pequeño) fuera lo suficientemente grande como
%  para hacer un pipeline 100 por 100 eficiente (no dejar nunca de
%  transpitir por esperar a un ACK), entonces la transmisión sería fluida
%  y constante a $R$ bps. Sin embargo, si el tamaño del buffer de emisión
%  de A fuera demasiado pequeño, la emisión sufriría pausas.
%
\end{verbatim}

% 10
\item {\bf ($2$ puntos)} En un router $R_1$ al que tiene acceso
  ejecuta ``\texttt{/sbin/route}'' y obtiene la siguiente salida:
\begin{verbatim}
Tabla de rutas IP del núcleo
Destino        Puerta de Enlace Máscara         Banderas Interfaz
214.97.254.0   *                255.255.255.252 U        eth0
214.97.254.0   *                255.255.255.0   U        eth1
214.97.255.128 214.97.255.129   255.255.255.128 UG       eth2
214.97.255.0   214.97.254.1     255.255.255.128 UG       eth0
default        *                0.0.0.0         U        eth3
\end{verbatim}
%R_1:
%
%Prefijo                   Redes               Interface
%------------------------  ------------------- ---------
%214.97.1111 1110.0000 00  D                   D
%214.97.1111 1110.         A                   A
%214.97.1111 1111.1        C y F               F
%214.97.1111 1111.0        B y E               D
%default                   Internet            Gateway

En un router $R_2$ al que tiene acceso ejecuta ``\texttt{/sbin/route}''
  y obtiene la siguiente salida:
\begin{verbatim}
Tabla de rutas IP del núcleo
Destino        Puerta de Enlace Máscara         Banderas Interfaz
214.97.255.128 *                255.255.255.252 U        eth0
214.97.255.128 *                255.255.255.128 U        eth1
214.97.255.0   214.97.255.1     255.255.255.128 UG       eth2
default        214.97.255.130   0.0.0.0         UG       eth0
\end{verbatim}
%R_2:
%
%Prefijo                  Redes               Interface
%------------------------ ------------------- ---------
%214.97.1111 1111.1000 00 F                   F
%214.97.1111 1111.1       C                   C
%214.97.1111 1111.0       B y E               E
%default                  A, D e Internet     F

En un router $R_3$ al que tiene acceso ejecuta ``\texttt{/sbin/route}''
  y obtiene la siguiente salida:
\begin{verbatim}
Tabla de rutas IP del núcleo
Destino        Puerta de Enlace Máscara         Banderas Interfaz
214.97.255.0   *                255.255.255.252 U        eth0
214.97.255.0   *                255.255.255.128 U        eth1
214.97.255.128 214.97.255.2     255.255.255.128 UG       eth0
default        214.97.254.2     0.0.0.0         UG       eth2
\end{verbatim}
%R_3:
%
%Prefijo                  Redes               Interface
%------------------------ ------------------- ---------
%214.97.1111 1111.0000 00 E                   E
%214.97.1111 1111.0       B                   B
%214.97.1111 1111.1       C y E               E
%default                  A, D e Internet     D

Determine la topología con la se interconectan los tres routers y las
direcciones IP asignadas a cada uno de sus interfaces (cuando sea posible).

\begin{verbatim}
% 
% Ver ejercicio 13, Junio, 2007.
% 
% Dibujamos cada router por separado y podremos ver, facilmente, cómo
% estan interconectados. Sólo hay que colgar la correspondiente sub-red
% o sub-redes de cada enlace.
% 
% R_1:
% A través de eth0 se conecta a R_3. IP = 214.97.254.1
% A través de eth1 no se conecta a ningún router.
% A través de eth2 se conecta a R_2. IP = 214.97.255.129.
% A través de eth3 se conecta a Internet.
%
%                  [214.97.254.0/25]
%                          |
%                         eth1
%      Internet------eth3 R_1
%                      eth2 eth0
%                       /     \
%          214.97.255.129    214.97.254.1
%       [214.97.255.128/25] [214.97.254.0/30]
%                           [214.97.255.0/25]
%
%
% R_2:
% A través de eth0 se conecta a R_1. IP = 214.97.255.130.
% A través de eth1 no se conecta a ningún router.
% A través de eth2 se conecta a R_3. IP = 214.97.255.1.
%
%       [214.97.255.128/30]
%          214.97.255.130
%               /
%             eth0
%             R_1 eth2---214.97.255.1 [214.97.255.0/25]
%             eth1
%              |
%     [214.97.255.128/25]
% 
% R_3:
% A través de eth0 se conecta a R_2. IP = 214.97.255.2.
% A través de eth1 no se conecta a ningún router.
% A través de eth2 se conecta a R_1. IP = 214.97.254.2
%
%                                  214.97.254.2
%                                        \
%                                       eth2
% [214.97.255.0/30] 214.97.255.2---eth0 R_3
% [214.97.255.128/25]                   eth1
%                                         |
%                                 [214.97.255.0/25]
\end{verbatim}

\end{enumerate}

\end{document}

