UTNianos

Gente una pregunta, donde dice "que pasa si en windows usas un recv no bloqueante?" yo no hice mucho de la parte windows, hice todo lo de linux, lo unico que se me ocurre de esa pregunta es que si el recv no es bloqueante, el codigo que sigue al recv seguiria ejecutandose sin esperar al recv y ocurriria un error porque tal vez el recv no recibio aun lo que esperaba, esto es asi o mando fruta?

Gracias!!!

thewithin escribió:Gente una pregunta, donde dice "que pasa si en windows usas un recv no bloqueante?" yo no hice mucho de la parte windows, hice todo lo de linux, lo unico que se me ocurre de esa pregunta es que si el recv no es bloqueante, el codigo que sigue al recv seguiria ejecutandose sin esperar al recv y ocurriria un error porque tal vez el recv no recibio aun lo que esperaba, esto es asi o mando fruta?

Gracias!!!

exactamente eso, si vos haces un recv no bloqueante y no haces ninguna comprobación podes perder datos. Y lo que podría ser peor, en el siguiente recv que hagas de ese mismo socket te van a entrar datos viejos, enquilombandote todo

Me contaron que ayer volaron a varios en el coloquio, y era gente que trabajo :s

Desde yá tenés que conocer como funciona todo el TP. Si solamente hiciste el servidor Caché, se cae de maduro que tenés que saber como funciona lo demás.

Yo considero que de los componentes que se desarrollaron el que más importancia hay que darle es el cliente (justo el que yo no codifiqué...) por el tema que ahí tenés que usar la API de Windows.

Primero le preguntan a cada uno qué porcentaje hizo del TP, cosa de ver a quién le hace más preguntas, o sobre qué plataforma... de todos modos preguntan parejo y tenés que saber todo. Algunas de las cosas sobre las que nos evaluaron para tener una idea:

- Tener bien en claro todo el tema de los Heaps (manejo de memoria, cómo la asignamos, liberamos, etc.) y cómo lo implementamos esto en Linux, qué similitudes/diferencias hay;
- si se puede pasar el código de Linux (cumpliendo con los estándares ANSI, bla bla) a Windows y por qué;
- cómo funciona la función fork() y preguntas sobre la manipulación de la memoria cuando se crea un nuevo thread;
- cuáles son los pasos para levantar un servidor (sea cual sea), es decir, primero creamos una estructura para el descriptor, luego usamos la función socket(), luego... acá tener bien en claro el select();
- te comentan que hay un servidor y que le ponen TTL "n", y pasa por dos servidores, bueno cuál es el valor del TTL y Hops después de eso;
- también hacen algunas preguntas sobre el Payload, ¿qué podemos meter ahí? Te dicen una cadena y tenés que decir que pasa si pretendés enviar eso;
- si se hacen dos búsquedas simultáneas con el mismo Search Criteria, ¿qué pasa? ¿hay algun conflicto? ¿por qué?;
- se puede usar fread() o read() en lugar de recv() (algo así era la pregunta, no me acuerdo exactamente), ¿por qué? ¿cuál es la función más genérica que hay?;
- ¿cómo hago para conectarme a otro servidor? ¿de qué forma se envía la IP? (tenés que decir que se guarda en una variable de tipo "unsigned long"... si leiste la especificación Gnutella la sacas de una);
- si tengo "n" threads en Windows, ¿cómo hago para manejarlos a todos? (tenés que contestar que primero los guardamos en una lista, luego como debemos pasárselo a la función WaitForMultipleObjects() y este tiene como argumento un array, debemos primero crear una vector dinámicamente)

Si ven que respondés dudando te "retienen" y te hacen más preguntas individualmente.

Saludos, espero que haya servido de guía! :)

Buenas, yo rendi el coloquio el sabado, eramos 5 y cayo uno en el coloquio, era el pibe que no habia tirado una sola linea, sin embargo siempre estubo cuando nos juntamos a hacer el tp y trabajo en los testings del sistema, un garron.

Bueno comento masomenos lo q nos preguntaron (Nos tomo diego marafetti):
-Que porcentaje del tp hizo cada uno. (No respondimos a esa pregunta)
-Select, como funciona, para que sirve, que problemas tiene con la espera activa.
-Fork, si declaro una variable global y hago un fork, deberia sincronizar los procesos para accedera a dicha variable? (Falso, porque el segmento datos se copia para el nuevo proceso)
-Nos dio un puerto (68245 algo asi) y pidio pasos para levantar un servidor (No se podia porque el puerto es mayor a 65535) pero aun asi, bue los pasos: socket, bind, listen, accept, select. Con su respectiva explicacion.
-Read, fread, recv... una es una llamada al sistema (Respuesta: Read) y como se relaciona con las demas, puedo usar cualquiera para recibir de un socket? Respta: Claro que si, las otras funciones internamente hacen alguna gilada para mas control, y terminan llamando a Read, ya que es la llamada, y no olvidemos que un socket no deja de ser un archivo.
-Funciones para manejar Heap en windows? (HeapAlloc, HeapCreate,HeapFree, HeapDestroy y que hace cada una)... si llamo en un thread a HeapAlloc, puedo pedir memoria del Heap del proceso principal? Claro!, es mas malloc funciona asi, pide memoria en el heap principal, no necesitas hacer un createheap antes.
-Si tengo 2 clientes y busco al mismo tiempo lo mismo, para el servidor presenta un problema? no, porque tienen distinto id de mensaje y ademas, por mas de que se presione al mismo tiempo la tecla, en la computacion los datos no llegan al mismo tiempo por el bus, siempre va a llegar uno antes que el otro, pudiendo asi sincronizarse (con select por ejemplo).
-Nos pregunto como habiamos tratado los HTTP en el servidor de archivos, bla, explicar codigo.
-Si mando un mensaje con TTL 2, puedo recibir una respuesta con Hops 3? NO!
-Explicacion de network byte order, big endian, como la mandas a la red y esas cosas. Rta: COn las funciones inet_addr, htons, y esas cosas, uno pasa los datos a network byte para enviarlos a la red, dentro de la estructura sockaddr, bla, chamuyo.
-Que pasa si hago un recv no bloqueante?, nada, va a devolver -1 y vamos a terminar en un caso de espera activa seguramente. Mejor usar select para controlar las llamadas bloqueantes.
-Que es el parametro HEAP NO SERIALIZE? Acceso no serializado al heap, una cosa rara, no pude encontrar una verdadera explicacion.
-Todas las señales se pueden atrapar? Como? Rta: Todas no, sigkill y sigstop no se pueden atrapar. Porque? porque podriamos crear procesos infinitos sino, es un control para poder siempre sacar a un proceso del ciclo de vida. Se atrapan con signal o con sigaction.
-Como funciona signal? Se incluye signal.h, vienen definidas las constantes de las señales del sistema, uno llama a la funcion signal y le pasa un numero de señal y el puntero a una funcion que se ejecutara cuando llegue dicha señal. Una vez que llegue dicha señal, habra que llamar devuelta a signal para atrapar nuevamente la señal, osea que dentro de la funcion donde se trata a signal hay q llamar a signal nuevamente, sino una vez que llegue la señal por segunda vez, se producira la accion por defecto, en caso de USR1 y 2, se terminara el proceso, nada bueno.
-Diferencias entre CreateThread y beginthreadex. CreateThread es la APi, beginthreadex la llama adentro, pero hace unos controles antes, porque con createthread tenemos problemas con las variables de tipo STATIC que usan las bibliotecas standard de C, si hacemos strtok en dos threads, bueno creo que me entienden lo llamamos con dos cadenas distintas, y la static quedara apuntando a la segunda, entonces el thread que la llamo primero perdera los datos.
Otra diferencia: MEmory leaks, no se libera bien la memoria al cerrar el thread, posiblemente.
-Sincronizacion en windows... bla. Waitforsingle, ReleaseSemaphore... blabla

Creo que no me estoy olvidando de nada, Saludos!

-

--

Tremendo! Gracias a todos por comentarnos como viene la mano, ayuda mucho!!!

Como nota de color: El ayudante hace caras (al estilo "me estas re chamuyando!!!"). No le den bola.

Agrego para contribuir un poco que el tema del flag HEAP_NO_SERIALIZE, lo que afecta es que no asegura la mutua exclusion, osea, vos pedis o liberas memoria desde 2 thread al mismo heap, con ese flag, y pueden ocurrir corrupción de memoria.
El uso de los otros flag que serializan disminuye un poco el rendimiento. Igual en nuestro caso esto no afectaba, porque si desde los thread se necesitaba memoria dinámica había que crear el heap, así que no había problema.