fedex86 escribió:hola yo lo hice como dijo adriano, no como dice teseracto (sí y como dice el protocolo gnutella), osea el sistema funciona perfecto en las pruebas eso no va saltar seguro, pero si en el coloquio si me preguntaban como lo hice. acaso esta muy mal!!?????

Sí, está muy mal.

fedex86 escribió:osea es motivo de desaprobacion del coloquio eso???

Puede ser. Estudiate el protocolo.

fedex86 escribió:si me desaprueban por eso en el coloquio supongo que te mandan a la prox instancia de recuperatorio del tp, no???, porque no es que no hice nada del tp es que lo hice mall!!!

No hay recuperatorios en el colóquio.

xtremenaza escribió:Tengo entendido que del coloquio no hay recuperatorio, a lo mejor me quivoco pero es lo que nos dijeron en algun momento.

La idea del colóquio es ver si trabajaste/estudiaste. No tiene mucho sentido un recuperatório :p

Es como te dijeron arriba, si trabajaste e investigaste aprobás seguro.

Dem0 escribió:

xtremenaza escribió:Tengo entendido que del coloquio no hay recuperatorio, a lo mejor me quivoco pero es lo que nos dijeron en algun momento.

La idea del colóquio es ver si trabajaste/estudiaste. No tiene mucho sentido un recuperatório

Con un amigo tenian dudas, dado que su coloquio escrito no estaba bien y lo cagaron a preguntas durante 15 minutos y les respondio todo bien... ese es el tipo de "recuperatorio" que podes tener.....

Adriano escribió:

Dem0 escribió:

xtremenaza escribió:Tengo entendido que del coloquio no hay recuperatorio, a lo mejor me quivoco pero es lo que nos dijeron en algun momento.

La idea del colóquio es ver si trabajaste/estudiaste. No tiene mucho sentido un recuperatório :p

Con un amigo tenian dudas, dado que su coloquio escrito no estaba bien y lo cagaron a preguntas durante 15 minutos y les respondio todo bien... ese es el tipo de "recuperatorio" que podes tener.....

Claro, eso sí. Cuando estás en el borde te piden que te queres un rato más para preguntarte un par de cosas.

Cita:Es como te dijeron arriba, si trabajaste e investigaste aprobás seguro.

No se.... digamos, en mi grupo, yo programe todo el cliente, y de linux no toque una goma... Y realmente no me acuerdo los parametros de CreateFileW, y cosas asi :S...

Cita:hola yo lo hice como dijo adriano, no como dice teseracto (sí y como dice el protocolo gnutella), osea el sistema funciona perfecto en las pruebas eso no va saltar seguro, pero si en el coloquio si me preguntaban como lo hice. acaso esta muy mal!!?????

La idea del TP es aplicar el protocolo. Si aplicas el protocolo mal, el tp estaria desaprobado.... Aunque habria que ver si se dan cuenta. Podes zafarla.... pero quedara en tu conciencia, si no es que yo me estoy equivocando... por las dudas chusmea el protocolo de ruteo.

Gracias por las repuestas, ya cambie el manejo del ttl, ahora lo hice como dice el protocolo era una boludes lo único que tenia que hacer es decrementar el ttl y cambiar un if, todo lo de mas estaba bien.
Igual de la otra manera que lo teniamos funcionaba bien, es mas en la primera correccion todo lo que tenia que ver con el ttl y los renvios de ping pong query y queryhit anduvo perfecto, si no hubiesemos tenido un problema en otro lugar ( que nada que ver con esto de los ttl) hubiesemos aprobado el tp, y que pasaba si en el coloquio me preguntaban como hiciste lo del ttl, le iba a decir como lo hice porque en ese momento no sabia que lo habia hecho mal ( osea lo habia entendido mal) que me desaprueban el coloquio o el tp?, segun lo que me contestaron desapruebo el coloquio, pero si le contesto todo lo de mas, porque no es que me rasque, estuve involucrado en toda la parte de linux es mas esa parte la hicimos entre dos con lo cual trabaje bastante ( lo unico, no toque nada del cliente pero bue).
Osea el coloquio es para que se den cuenta si laburaste o no, y las pruebas del tp son para ver si hicistes bien el tp, creo que si en el coloquio se dan cuentan que hicistes algo mal del tp no te tendrian que desaprobar el coloquio te tendrian que mandar a otra instacia de recuperatorio del tp ( osea parte practica), y si es una boludes lo que hiciste mal, la tendrian que dejar pasar.

fedex86 escribió:Osea el coloquio es para que se den cuenta si laburaste o no.

No. El coloquio es para ver si trabajaste y aprendiste. A una compañera mía la reprobaron porque no supo relacionar el concepto de "espera activa".

fedex86 escribió:y si es una boludes lo que hiciste mal, la tendrian que dejar pasar.

Pero lo tuyo no es una boludez. Pifearle al protocolo es algo grave que afecta el correcto funcionamiento del sistema.

Una boludes sería calcular mal el "kernel time" en el log de cliente.

Teseracto escribió:

Cita:Es como te dijeron arriba, si trabajaste e investigaste aprobás seguro.

No se.... digamos, en mi grupo, yo programe todo el cliente, y de linux no toque una goma... Y realmente no me acuerdo los parametros de CreateFileW, y cosas asi :S...

No son exigentes con esas cosas, como mucho las diferencias entre algunas de las funciones de la API de Windows y la estandar. Sí, por ejemplo, piden los parámetros de send, el recv y el select (que aparecen en todos los programas del TP).

Por lo menos a mi me tomaron principalmente como solucionaste los errores más comunes (que ellos tienen en claro cuales son) y los conceptos teóricos que aplicaste.

Si ya se que no era una boludes, que de la manera que lo habia hecho no respetaba el protocolo gnutella, con lo cual cambie la arquitectura que tenia que tener el sistema en esa parte, osea no es lo que pidieron ellos, por eso como dije arriba ya lo cambie, y no me referia a esto cuando decia que si es una boludes la tendrian que dejar pasar, me referia a otra cosa.
Y una cosa lo de espera activa se refiere a la manera en que vas a espar por ejemplo por un proceso hijo , porque me acuerdo que vi algo de eso para el trabajo en la parte cuando hago fork para ejecutar el uploader, pero no use espera activa porque eso no me deja que el servidor de archivos (el padre) ejecute otras cosas, asi que lo maneje con señales, para capturar la señal del exit del hijo asi no queda zombie.
supongo que esta bien eso no?
es mas ahora me acuerdo que ne la cursada nos dijeron que no es recomendable usar espara activa porque es un uso de cpu inecesario

if((--buffer->TTL)>0) replegar...

eso le costo la vida a muchos... nosotros caimos en la de los 3 procesos xD

acabo de darme cuenta que teníamos otro topic donde se habla del coloquio: ingenieria-en-sistemas-de-informacion-f39/presentacion-so-t1203.html (por ahí hay algún otro dato interesante)

si bien no van a revisarles el código, es importante que respeten el protocolo. para poder responder bien las preguntas que les hagan, y para hacer lo que les piden.
una prueba muy turra sería que conecten 2 clientes de distintos grupos, y si respetan el protocolo debería funcionar todo de 10, no? eso estaría muy bueno. jaja.

por último, ojo con lo que escriben en el foro. puede haber ayudantes dando vueltas por ahí. ;-)

LeaTex escribió:por último, ojo con lo que escriben en el foro. puede haber ayudantes dando vueltas por ahí. ;-)

Off-topic:

Presiento que Uther esta aqui... porque todos tenemos un Uther adentro... y es que nos estamos comiendo a Uther... MUAJAJAJA... olviden lo ultimo

Che... adhiero a Leatex... no cuenten sus problemas aqui xD
y recuerden (para otros topics) que de hecho hay algunos profesores registrados!

Off-topic:

A menos que hayan aprobado... (yo todavia recuerdo la "Anomalia de Adriano"... un bug que encontre un dia antes de la entrega y se basaba en que si uno levantaba dos procesos simultaneamente en dos maquinas diferentes, como ambos estaban leyendo los archivos de configuracion, no se enteraban que el otro estaba activo y no se conocian... la solucionamos en la entrega final con.......... backspace! ... basicamente, evitamos levantar dos procesos con menos de dos segundos entre uno y otro... cuando fue necesario tipeamos mal, y la tecla backspace nos dio el segundo extra xD)
Ahora que lo menciono... es importantisimo que, si no pueden solucionar un error (porque estan en el horno, y les queda poco tiempo para entregar y no llegan) traten de acotarlo, y de saber como se produce y como se puede evitar... si son conscientes de sus errores, no se llevaran sorpresas... ningun sistema esta PERFECTAMENTE codeado, pero es fundamental que lo conozcan al 100%

Y si quieren otra anecdota de la entrega final... estabamos levantando los procesos y yo a mano escribi en la consola "SEGMENTATION FAULT" y uno de los pibes de mi grupo casi se muere de un infarto... cuando le dije que era un chiste (despues de muchas muchas noches de dormir 3 horas) me querian matar xD

El mismo creador del foro, el señor(?) LeandroDG, es ayudante de la matéria.

Tampoco le estamos haciendo la taréa, él pregunto que tán adentro de la mierda estaba y nosotros tratamos de darle una medida razonable. Además el sabía cual eran sus errores, y ya los corrigió XD.

Cita:Y si quieren otra anecdota de la entrega final... estabamos levantando los procesos y yo a mano escribi en la consola "SEGMENTATION FAULT" y uno de los pibes de mi grupo casi se muere de un infarto... cuando le dije que era un chiste (despues de muchas muchas noches de dormir 3 horas) me querian matar xD

JAJAJAJAJAJAJAJAJAJAJAJAJAJAJAJAJAJAJAJAAJA

Cita:una prueba muy turra sería que conecten 2 clientes de distintos grupos, y si respetan el protocolo debería funcionar todo de 10, no? eso estaría muy bueno. jaja.

Fruta. El protocolo IRC/IPC tiene definidos nomas la interpretacion de: El ID y el Payload Length (y creo que algo mas). El Payload Descriptor lo toma uno como se le antoje, por lo que es el mismo protocolo para "comunicarse" pero no para "entenderse".

Off-topic:

Junto con esto:
humor-f54/nuevo-tipo-de-organigramas-mas-visuales-t1772-15.html#p22833

DOUBLE FAIL!!!!

Teseracto escribió:

Cita:una prueba muy turra sería que conecten 2 clientes de distintos grupos, y si respetan el protocolo debería funcionar todo de 10, no? eso estaría muy bueno. jaja.

Fruta. El protocolo IRC/IPC tiene definidos nomas la interpretacion de: El ID y el Payload Length (y creo que algo mas). El Payload Descriptor lo toma uno como se le antoje, por lo que es el mismo protocolo para "comunicarse" pero no para "entenderse".

me remito a mi última frase: eso estaría muy bueno.

no tengo ni idea de cómo son los TPs en este siglo. cuando lo hice yo no sonaba tan loco eso de conectar varios clientes diferentes.
es como que me digas que 2 clientes de FTP no se pueden conectar al mismo servidor. si se respeta un protocolo, debería poderse. pero bueno, no sé cómo son los TPs ahora, tal vez cambiaron bastante.

LeaTex escribió:

Teseracto escribió:

Cita:una prueba muy turra sería que conecten 2 clientes de distintos grupos, y si respetan el protocolo debería funcionar todo de 10, no? eso estaría muy bueno. jaja.

Fruta. El protocolo IRC/IPC tiene definidos nomas la interpretacion de: El ID y el Payload Length (y creo que algo mas). El Payload Descriptor lo toma uno como se le antoje, por lo que es el mismo protocolo para "comunicarse" pero no para "entenderse".

me remito a mi última frase: eso estaría muy bueno.

no tengo ni idea de cómo son los TPs en este siglo. cuando lo hice yo no sonaba tan loco eso de conectar varios clientes diferentes.
es como que me digas que 2 clientes de FTP no se pueden conectar al mismo servidor. si se respeta un protocolo, debería poderse. pero bueno, no sé cómo son los TPs ahora, tal vez cambiaron bastante.

Pasa que (básicamente) la comunicación ClienteWIndows-ServidorLinux no usa un protocolo fijo. Cada uno lo diseña como quiere.

El protocolo fijo (Gnutella) se usa en la comunicación entre ServidorLinux-ServidorLinux. Ahí sí te pueden meter otro servidor diferente y tendría que funcionar.