Mejora protocolo tcp


([N1] wikan) #1

Buenos días, no se si voy a escribir disparates o hasta que punto puede interesar. Pero se me han ocurrido unas mejoras en el protocolo tcp y antes de ponerlo en ideas me gustaría saber la opinión.

Ahora mismo es, conectado, haces y desconecta. Por lo que no es posible mantener conexiones abiertas.
Propongo añadir eventos al protocolo tcp donde...empieza el delirio

Servidor:
- Evento: OnConnect
Se dispara cuando se conecta el socket.
- Evento: Onreceived
Disparado cuando recibimos datos
- Evento: OnDisconnect
Disparado cuando el cliente desconecta

Con esto podríamos mantener sockets abiertos con lo que podríamos por ejemplo:
- Avisar a nuestros clientes cuando ha ocurrido algo y mandar a refrescar cierto control sin tener que usar timers para refrescar.
- Mantener una tabla con los clientes conectados
- En web mantener conexiones abiertas y hacer push

Cliente:
Ahora mismo es imposible enviar algo con un cliente que use un mismo puerto con otro proceso que escuche ese puerto. Así que...

OnConnect
Cuando el cliente conecta el socket con un remoto
OnDisconnet:
Cuando a conexión es cerrada o perdida con el socket remoto

Eventos-Funciones
Poder definir tantas funciones como queramos dentro del mismo objeto y así en EjecutarFuncionCliente (no recuerdo si es el nombre exacto) poder elegir la función que vamos a usar y enviar y recibir del socket remoto tal y como se hace ahora.

No se si estaré diciendo disparates, pero creo que el poder mantener conexiones nos daría aún mas juego con el protocolo.


([N4] velavisual) #2

@manuel
.
.
+100
.
.
Al menos la idea principal debería consistir en dejar la conexión abierta hasta que se le diga lo contrario.
.
Yo aún no sé cómo mantenerla abierta, ya que no sé cuando realmente voy a recibir paquetes de información.
Personalmente cuando lo descubrí (o no sé cómo hacerlo) lo tomé como una gran putada.
.
Desconozco si con Javascript se puede hacer algo al respecto, - lo de mantener la conexión abierta-.
Si algún Javero sabe cómo se puede hacer, se lo agradeceríamos.
.
.
saludos
Antonio Vela
http://www.velavisual.com


([N1] Roberto Blasco) #3

velavisual

Java != Javascript

:-)

Un saludo. Roberto Blasco.


([N4] velavisual) #4

@Roberto
.
Otro agujero que tapar
.
Manos a la obra y para el próximo evento lo presentas, gege
.
Mientras yo leo cositas sobre Node.js


([N1] filipeagg) #5

Al menos en las versiones anteriores de v7, me funciona correctamente, de hecho tengo un tcp en producción y no se cierra.
Lo tengo como mini servidor web. Como mínimo a cada 10 minutos recibe una petición. Eso si, lo tengo abierto en un vclient no en servidor.


([N1] wikan) #6

@velavisual
Yo también he pensado en eso. Cuando salga a público el javascript en procesos y se puedan hacer includes. Quizás se podría meter node.js o socket.io. Es una opción, pero creo que ambos usan el V8 de google y las qt que lo llevan son las 5 y nosotros si no me equivoco seguimos por las 4.7.2

@filipeagg
Pero el socket se mantiene conectado? O recibe una conexión, realizas lo que necesites y cierra la conexión con el cliente?
Yo me refiero, no a tener un puerto escuchando. Lo que digo es que cuando un cliente se conecte, ya sea un vClient o otra aplicación. Haga eso, conectar y ya yo mandaré la información cuando lo necesite.
En tu caso te vendría de lujo para hacer push. Cuando el servidor tiene un cambio lo difunde sin tener a los clientes....tengo algo?, tengo algo?


([N1] adelo) #7

Al menos antes, que yo sepa, se mantenía abierto hasta que tu lo cerrases.


([N1] wikan) #8

@adelo
¿Te refieres al puerto del servidor? Si, es cierto.
Pero cuando ejecutas una función cliente del protocolo. Hace lo que necesites y cierra.

Pongo un ejemplo.
Un sistema de mensajes
Ahora: Los clientes tendrían que tener un timer para ver si hay nuevos mensajes

Pudiendo mantener conexiones abiertas. Conecto un puerto del cliente al servidor y cuando hayan nuevos mensajes para el usuario que tengo abierto, le envio información al cliente para recargue la lista de mensajes. Por lo que el consumo de ancha de banda se reduce a lo necesario.


([N1] Pepeto) #9

Listado de novedades en la versión 7.8:
http://velneo.es/listado-de-cambios-de-velneo-v7-7-8-0/

Los protocolos ya están operativos en 2º y 3º plano
Ya es posible poner a la escucha protocolos TCP en 2º y 3º plano. Esto permite arrancar un servicio TCP sin afectar al interfaz de la aplicación. Cuando se inicia en 2º plano, si no se programa su cierre lo hará automáticamente al finalizar el vClient como ocurre también en 1º plano, . En 3º plano el puerto seguirá a la escucha hasta que se termine el servicio con el comando de instrucción en un proceso en 3º plano o en el ON_CLOSE_SERVER, y también cuando se pare o reinicie el servicio vServer. (2816)

En cualquier caso, aunque es posible poner un puerto a la escucha directamente desde el servidor, no es recomendable.
http://velneo.es/listado-de-cambios-de-velneo-v7-7-7-0/

un saludo
José Luis
http://www.ascsl.com


([N1] wikan) #10

Creo que no me explique bien o no se me ha entendido


([N1] adelo) #11

@manuel.rd.gmail
Quizá no haya entendido bien la cuestión, pero yo tengo varios programas con mensajería interna entre los clientes conectados y solo abro el protocolo de escucha una vez en el on-init de la aplicación cliente y lo cierro en el on-close.

De hecho, puede recibir varios mensajes a la vez emitidos por distintos clientes.


([N1] filipeagg) #12

@manuel.rd.gmail

Hola, lo que quieres hacer es push usando tcp. Lo protocolo tcp en velneo en ese sentido funciona como deberia funcionar (igual que cualquier otro protocolo tcp en cualquier otro lenguaje).

Yo en v6, tengo push implementado, pero lo tienes que implementar tu.

En v7, aun no lo he probado, pero la teoria consiste en abrir un puerto en servidor, y cuanda vez que se inicia un cliente, tienes que lanzar un proceso en segundo plano que se conecte al servidor.

En esa primera conexion tienes que jugar con los timeouts de las instruciones, tienes que colocar un timeout alto del lado del cliente, y del lado del servidor un for y controlar el tiempo que tienes la conexion retenida. en cada ciclo del for, controlas si hay algo para enviar a ese cliente.

Si el tiempo pré-estabelecido pasa, el servidor tiene que liberar la conexión, y el vclient, tiene que realizar otra (lo que se llama keepalive).

De todas las formas no es una problematica de velneo, solo hace muy pocos años, se ha empezado a solucionar esta problematica, que al dia de hoy aun es muy dificil de solucionar, sea cual sea en lenguaje de programación.




([N1] wikan) #13

@filipeagg
Correcto, esa era precisamente mi tarea de laboratorio esta semana. Era justo lo que había pensando.
Aunque creo que estando cliente y servidor en el mismo equipo es imposible hacerlo. Al tener el servidor escuchando ese puerto, creo que los clientes no pueden usar ese puerto. Creo.....


([N1] filipeagg) #14

@manuel.rd.gmail
Manuel como te comento el puerto solo está abierto en el servidor.
En el vclient no es necesario abrir cualquier puerto.


([N1] wikan) #15

@filipeagg
Por lo menos a mi no me sale. En el mismo ordenador tener el vServer escuchando un puerto y un vClient haciendo una petición.
Sin embargo, si lanzo la petición desde un navegador me devuelve un texto que tenga en el protocolo del servidor.
Por lo que lo veo una limitación, no grande, pero si para desarrollar por lo menos