Fw: [Final_REDES: 120] Re: [RDI_FRBA] [Redes] Final de Julio de 2007

[Gabriel Przybylski]

From: Leticia Brey

To: final...@googlegroups.com

Sent: Sunday, August 01, 2010 8:22 PM

Subject: Re: [Final_REDES: 120] Re: [RDI_FRBA] [Redes] Final de Julio de 2007

 en verde mis comentarios

El 1 de agosto de 2010 20:11, Gabriel Przybylski <gpr...@gmail.com> escribió:

a)      Cuantos bytes intercambiaron en cada sentido durante la conexión cliente y servidor?

Cliente – servidor= 235

Servidor – cliente= 515

10.200.128.231

200.69.2.54

2187 > http [ack] seq=236 ack=515 win=65022 len=0

no deberían ser 514 en vez de 515?

la ultima trama tiene seq 515 por eso puse eso. 

en general creo que no es muy fiable guiarte por el numero de secuencia porque indican la posición del 1er byte de datos del paquete y no dicen nada de cuántos bytes viajaban en ese paquete.

viendo este caso puntual, no entendo mucho q paso!

x	10.200.128.231	200.69.2.54	2187 > http [fin, ack] seq=235 ack=514 win=65022 len=0
x	200.69.2.54	10.200.128.231	http > 2187 [fin, ack] seq=514 ack= 235 win=6432 len=0
x	10.200.128.231	200.69.2.54	2187 > http [ack] seq=236 ack=515 win=65022 len=0
x	200.69.2.54	10.200.128.231	http > 2187 [ack] seq=515 ack= 236 win=6432 len=0

 

en el 2do reglon, en el ack dice 235, como si no hubiera llegado (o no le diera pelota) al fin que ´se mandó en el 1er reglon.

después sigue como si nada.

 

**************************************************************

más alla de todo esto, quisiera saber a qué se refiere con "bytes intercambiados". xq al hacer FIN y SYN, el nro de secuencia y ack avanzan, pero es puro flag de header TCP, 0 datos!

piden datos puros? piden cuantos "nros de secuencia" fueron confirmados? cómo se obtiene lo que piden??? HELP!!!

 

 

La ip 192.168.0.223 corresponde a la dirección de broadcast de una subred. Indique:

a)      Cuál es la dirección de red?

192.168.0.0

 

dice de la red por eso puse esa, la que decis vos es la dir de la subred

q detallista! creo q quisieron poner la de subred... o eso quise creer!

192.168.0.223 ---> (desglosando el último octeto en el binario) 192.168.0. 11011111   si es de broad, entonces el host termina donde está el 0.

la dire de red será 190.168.0. 11000000 ,o sea, 192.168.0.192

la mascara será 255.255.255. 11100000 = 255.255.255.224

b)     Cuál es la máscara de subred apropiada?

255.255.255.192 de la subred 11111111.1111111.110 00000.00000000 (subred 6)

 

Calcule la eficiencia en la transmisión de un bloque de 100 bytes, utilizando los siguientes protocolos : tcp/ip/Ethernet (ni idea)

Tcp= 100/1560

Ip = 100/65536

Ethernet= 100/1518

de este tengo mis dudas... pero creo que lo q tenes q dividir son los 100B respecto de todo lo que se envía a través de la trama.

en ese caso, lo que se envía será:

8 + 6 + 6 + 2 + 4 = 26B de header y footer ethernet

20B de header IP

20B de header TCP

100B de datos

enonces, la eficiencia será            100 / (26 + 20 + 20 + 100) = 100 / 166 = 0,60 --> 60%

alguien puede confirmar esto???

me suena mas coherente je!

 

BC = 384 kb => /9000 => 40 tramas

BE= 192 kb => 20 tramas

Rechazadas = 20 tramas

Genera 83 tramas (800000/9600)

Tramas rechazadas = 83 - 40 - 20 = 23

Indiqui 3 ventajas de una red 100baseTX frente a una 802.11G NI IDEA!!!!

• es más rapida, ya q 100baseTX va a 100mbps y 802.11g va a 54mbps, que nunca se cumplen ¬¬
• es más segura ya q por ser wireless la 802.11 cualquiera puede escuchar el tráfico. en la 100btx tenes q conectarse fisicamente.
• 802.11 por ser wireless es mas propensa a interferencias, como prender el microondas o hablar por telefono inalámbrico, mientras que 100btx, si la instalaste bien, no va a tener interferencias
  
  seguro hay más ...gracias!!!

----- Original Message -----

From: Leticia Brey

To: rdi_...@googlegroups.com ; final...@googlegroups.com

Sent: Sunday, August 01, 2010 7:04 PM

Subject: [RDI_FRBA] [Redes] Final de Julio de 2007

Creo que es el último del día.
Tengo varias dudas con este.

[Leticia Brey]

Gabriel, recien leyendo unos apuntes vi que el nro de seq corresponde a los bytes enviados

[Federico Koval]

Hola, creo que soy el responsable de este ejercicio ...

 

Es correcto calcular la cantidad de bytes intercambiados como el Seq-1 y Ack-1.  Ahora, cuando se cierra la conexion, un extremo envia un segmento FIN sin datos, por lo que no podria avanzar el numero de secuencia. Si el extremo opuesto nos confirma la correcta recepcion del FIN con un ACK como esperamos, y el numero de secuencia no se modifico, como sabemos si el ACK corresponde al FIN o al ultimo segmento de datos enviados ?

Esta es la razon por la cual el intercambio de FINs y ACKs incrementa en 1 el numero de secuencia y acknowledgement sin que se envie  efectivamente un byte de datos adicional.

 

El resto esta todo correcto. Solo que por lo general cuando se calcula la eficiencia en el uso de Ethernet, se considera un overhead de 18 bytes (no se cuentan el preambulo ni el SFD).  La respuesta es correcta de todas maneras.

 

Saludos,

 

 

Federico.

El 1 de agosto de 2010 21:04, Gabriel Przybylski <gpr...@gmail.com> escribió:

[Leticia Brey]

una sola pregunta que no me queda claro porque es seq -1 ?

y no es seq

[Gabriel Przybylski]

Disculpá que tenga tantas dudas con este tipo de ejercicios pero en la cursada nunca vimos algo de esto...

 

Copio la captura entera

x	10.200.128.231	200.69.2.54	2187 > http [syn] seq=0 len=0 mss= 1460
x	200.69.2.54	10.200.128.231	http > 2187 [syn, ack] seq=0 ack= 1 win=5840 len=0 mss= 1380
x	10.200.128.231	200.69.2.54	2187 > http [ack] seq=1 ack=1 win=65535 len=0
x	10.200.128.231	200.69.2.54	get /favicon.icd http/1.1
x	200.69.2.54	10.200.128.231	http > 2187 [ack] seq=1 ack= 235 win=6432 len=0
x	200.69.2.54	10.200.128.231	http/1.1 404 not found - file doesnt exist or is read protected

x	10.200.128.231	200.69.2.54	2187 > http [fin, ack] seq=235 ack=514 win=65022 len=0
x	200.69.2.54	10.200.128.231	http > 2187 [fin, ack] seq=514 ack= 235 win=6432 len=0
x	10.200.128.231	200.69.2.54	2187 > http [ack] seq=236 ack=515 win=65022 len=0
x	200.69.2.54	10.200.128.231	http > 2187 [ack] seq=515 ack= 236 win=6432 len=0

 

Cómo calculo entonces los bytes en un ej como este, o en ejercicios en los que la conexión no se cierra y preguntan cuánto se transfirió hasta un cierto instante (como el que adjunto)?

 

Siguiendo la lógica que mencionás para el secuenciamiento del FIN, el incremento de secuencia que ocurre en el SYN no se considera en el cálculo?

 

Entonces en este ejercicios la respuesta sería:

Cliente-->servidor = 234   ya que en la linea azul se está mandando el fin con un nro de secuencia más que el último byte enviado, asi que hago 235 - 1 = 234

Servidor-->cliente = 514   ya que en la linea azul se está haciendo ack de 514 bytes que llegaron ok, antes d iniciar el fin

?

 

Y el que inició el cierre de conexión es 10.200.128.231? porque no veo claramente la secuencia

FIN  

        ACK   

        FIN

ACK

 

acá hay algo como

FIN

        FIN

ACK

        ACK

 

 

gracias!!

[Federico Koval]

Porque seq es el numero de orden del primer byte en el campo de datos. Entonces, se llevan enviados seq-1.