próximo »

[flacman]

buenas gente, pues hoy segui dandole un rato al chat y me di cuenta que el protocolo no está muy bien definido, o pues si lo está pero no la implementacion algoritmica de este, asi que oiga sugerencias (OJO, cuando digo algoritmo no me refiero a codigo, sino a procedimientos para lograr la conexion!). la idea es lo de sincronizar las conexiones y las desconexiones, asi que el que me kiera dar una sigerencia para antes del viernes (jeje ahi es cuando yo empiezo a pensar :p) se lo agradeceria muchisimo.

les recuerdo, no tiene que estar en java ni nada, es un algoritmo no un codigo. contal q sea entendible jeje. Kiero ver los supuestos "elites" q ayuden

[ze0n]

Kiero ver los supuestos "elites" q ayuden

Uppss!! Sarcasmo aparte xD..

Men, yo por mi parte... Poco conocimiento tengo sobre el algoritmo de conexión que está implementando... Opino, que si ud ya tiene uno definido, comentelo o digame donde está, si ya lo posteo.. y se arregla el que está...

Psss.. de todas formas, ya es tarde para mí ahora... Por lo tanto mañana temprano le dedico tiempo al protocolo (Sin saber sobre el que ud está implementando) y le doy un respuesta..

Nos vemos.

[flacman]

el protocolo que se va a usar es CUCP (ya sabe donde encontrarlo). pero pues me di cuenta que la implementacion no es tan fácil como pensaba. la idea es que me ayudaran a ver como lo implemento, pues de forma depronto mas detallada. lo que les digo, no interesa saber código, contal de decir "A conecta a B" basta. lo que necesito es todos los posibles escenarios.

como lo tenia pensado mas o menos era armando un thread para manejar el recivo de mensajes y otro thread para manejar el recivo de conexiones (y pbueno el thread principal que envia y controla todo), pero pues no kiero ponerme a armar 2 threads aparte del programa principal. el problema es q digamos para el recivo de mensajes tok hacer un ciclo infinito que se kede oyendo al socket hasta que uno pare al thread ( ya sea por que se desconecto o cualkier otra cosa por el estilo ).

aki posteo lo que tenia pensado (está hecho en java, las clases que interesan son las de la carpeta mundo), pero eso es solo para ocnexiones de 2 personas, lo q me causo problema es al acomodarlo a CUCP para recivir mas de 2 personas.

[c7b3r]

Tengo una idea flaco, como el chat usa la POO entonces para poder solucionar el problema de charla multiple, lo unico que tocaria hacer seria instanciar un arreglo de objetos de la clase que hace uso de las conexiones, asi cuando una persona quiera conectarse, el arreglo  instanciaria un objeto de la clase y la persona podra acceder facilmente al chat.

Ando echandole cabeza a la vaina de la sincronizacion de la desconexion, pero se podria implementar un boton de desconectar a un lado, este boton haria un .close() a la conexion, pero creo que se tendria que jugar con arreglos de conexiones.


saludos.

[flacman]

si eso ya está hecho, el problema es que bueno, el tipo A se desconecta, y que pasa con B? segun el protocolo se conecta con el siguiente, pero si no hay siguiente? como se procede con detalle. igualmente como se haria para aceptar a alguien. jeje mas bien, como implementar CUCP

[Alluz]

aich, yo no sé que hago por aca, no conosco el protocolo, pero bueno... creo que opinar no hace daño.

Para las desconexiones otros chats utilizan TimeOuts y para evitar la desconexión, periodicamente se envia un paquete al estilo de un "ping" que dice "hola, estoy vivo". Pero como esta implementación puede resultar en la mala suerte que precisamente en ese momento de enviar el paquete la red se caiga, se usan:

Ping normal [x segundos]= Hola, estoy vivo.
-->Si el ping normal no fue recibido, servidor envia:
Ping critico [y segundos]=Oiga ·$%&//, que pasa que no me envia ping
Respuesta ping critico= Aqui estoy
-->Si el ping critico no fue respondido
Ping desconexión [z segundos]=Adiossss

(pero seguramente eso ya lo habían pensado...)

Ahora, lo que dice el flaco:

el tipo A se desconecta, y que pasa con B? segun el protocolo se conecta con el siguiente, pero si no hay siguiente? como se procede con detalle.

Entonces uno piensa: ¡un hilo para manejar conexiones! y el flaco es muy explicito diciendo:

pero pues no kiero ponerme a armar 2 threads aparte del programa principal.

Pero eso está como medio complicado porque si nos se maneja otro hilo para las conexiones, creo que si uno está hablando con alguien, el ciclo principal tiene que manejar la conexión actual y además esperar conexiones adicionales y el programa se hace un poco más complicado de depurar.

Como dije al comienzo, no sé mucho sobre el tema.

[c7b3r]

offtopic:

flaco, lo mejor seria hacer otra reunion de sabado en la noche para cuadrar eso xD.

saludos.

[ze0n]

Bueno...

Pienso en esto:

1. A entra a la conversación, enseguida se genera el hilo de comunicación, que será el encargado del flujo de mensajes (programa principal), tanto de emisiónj, como de recepción.

2. B entra al canal, se encuentra a A... Luego no se genera el hilo, pss porque ya está creado, lo que se hace es darle acceso a B al hilo generado anteriormente, al A ingresar como pionero al canal. (esto no es sobre privilegios ni nada).

3. Entra C al canal, se encuentra a A y a B, luego se agrega C al hilo de conversación..

4. B se desconecta, queda A y C... Luego, el hilo no sufrirá ningún cambio, puesto que no es un hilo generado para cada usuario, sino que es un hilo principal compartido...

Así es mas o menos como lo pensé... Ya que Cheké levemente el protocolo planteado y ví, que ud lo que hace es generar un hilo con cada usuario que acceda al canal... Formando como un estrella..

Nos vemos.

[flacman]

1. A entra a la conversación, enseguida se genera el hilo de comunicación, que será el encargado del flujo de mensajes (programa principal), tanto de emisiónj, como de recepción.

para recivir mensajes tiene q estar constante mete reciviendolos, la implementacion es mas o menos asi: while(true) reciva;
por lo tanto ahi tendrian q haber 2 hilos, uno para recivir mensajes y otro para conexiones (justamente lo q no kiero)

2. B entra al canal, se encuentra a A... Luego no se genera el hilo, pss porque ya está creado, lo que se hace es darle acceso a B al hilo generado anteriormente, al A ingresar como pionero al canal. (esto no es sobre privilegios ni nada).

esto ta bueno, esta tarde lo analizo bien para implementarlo

Así es mas o menos como lo pensé... Ya que Cheké levemente el protocolo planteado y ví, que ud lo que hace es generar un hilo con cada usuario que acceda al canal... Formando como un estrella..

no se hace un hilo por cada persona, hasta ahora lo q he hecho son pruebas para comunicacion d solo 2 personas, la idea es que sea un circulo como se planteo en CUCP

[Khanzerbero]

si A se desconecta y B qda solo el siguiente en la lista es el....