Protocolo TCP

Velneo
1

Hola comunidad,

como imagino sabéis tenemos en V7 un objeto cojonudo llamado protoclolo TCP/IP con el que podemos enviar y recibir texto, archivos, bytes, etc. Pues bien, a ver si alguien nos puede ayudar: encontramos una limitación enorme a la hora de definir un destinatario puesto que el único parámetro que tenemos es una IP y eso en la nube es poca cosa o nada.

Es decir, un usuario de la aplicación está en una IP muy rara vez: lo normal es que esté por ejemplo en una IP local (192.168....) dentro de un dominio (80.25......) Para esto, la única posibilidad que tenemos es dirigirnos a cada usuario configurando puertos en su ruter y en su ficha en nuestra aplicación de manera que podamos enviar un mensaje por ejemplo a la IP 80.25.203.44 , puerto 695 (y que éste en el ruter este configurado para dirigirse al usuario).

La cuestión es que como os decía al principio esto es poco operativo en la nube puesto que ese mismo usuario puede estar por la tarde en su casa, o ser un vendedor y viajar y conectarse desde cualquier sitio y resolver mediante IP y puerto se queda bastante corto.

¿Hay por ahí alguien muy listo que se haya planteado esta cuestión y conozca algún truco, componente o dll que simule IPs ?

Aprovecho para saludar y agradeceros vuestra ayuda

2

Tienes razon, al decir que un usuario, muy rara vez puede tener la misma IP, ya que precisamente la tecnologia actual nos permite conectarnos desde cualquier lugar: casa con IP dinámica, la oficina con IP fija o dináimca, una Wifi publica, etc.

Pero también es cierto que el Servidor (vServer) si suele estar en una ubicación fija, y normalmente usando una IP fija.

Si es asi, quizá deberías plantearte que sea el usuario el que se conecte al servidor y no viceversa.
Además, el usuario no suele estar conectado constantemente, por lo que será mas fácil que sea el quien realialice las peticiones, y no que el Servidor de la oficina intente conectar con todos los usuarios de modo reiterativo.

No se si esto responde a tu pregunta, pero sin conocer el analisis del proyecto, es lo primero que se me ocurre.

un saludo
Jose Luis
http://www.ascsl.com
http://ascsl.net

3

Gracias Jose Luis pero no me sirve y es que no he contado el objetivo:

queremos hacer un sistema de mensajería instantánea parecido a los "telegramas" que había en v6 por lo que no me vale que el cliente se conecte al servidor, se trata de que cualquier usuario se comunique con cualquier otro .

4

@apinna
.
.
Perdón por la intromisión y expongo idea (que lógicamente ya la habréis pensado)
.
No sé si estoy equivocado o desconozco algo en v7.
.
Para que un usuario se pueda comunicar con otro desde un vclient deben estar conectado a un vServer, ¿no?
.
- Podrías tener una tabla mensajería en el vserver (fecha, HHMMSS, Usuario origen, usuario destino, mensaje...etc)
.
.
En los clientes, en el autoexec: Un dock actualizando cada x milisegundos, y visualizando las notificaciones de otros usuarios destinadas al cliente que conecta (con opción a responder) en un dock destinado a ello, también actualizable cada x milisegundos.
.
.
También te vale este sistema desde usuarios monopuestos y mediante funciones remotas, enviar y recibir....
.
Claro, que lo ideal es como dices, de cliente a cliente.
.
saludos

image

image

image

image

image

image

image

image

5

Gracias Velavisual por tu aportación, esta es la alternativa que me queda si no lo resuelvo vía TCP. El caso es que prefiero prescindir de timers para esto ya que al final siempre interfieren de una u otra manera en el trabajo del usuario.

¿Has visto el tutor de TCP? es acojonante ya que no tienes que usar un timer sino que simplemente tienes un puerto a la escucha y va como un tiro.

6

Lo que referes en el objecto TCP/IP no es una limitación, pero si una regla en la comunicación con el protocolo tcp/ip. Te explico:

Al contrario do que por veces pensamos servicios como el windows live menseger, skype o incluso el team viewer(para conectarse por escritorio remoto), para que puedan saltar esas restrinciones usan siempre uno o muchos servidores centrales. La lógica es:

Cuando se abre un cliente, este tiene que conectarse al servidor (alta de un registro), con su ip de origen y usuario identificado y fecha y hora, de esta manera existe siempre un equipo (el servidor) que sabe quien está conectado.

Si quiero enviar un mensaje desde un cliente a otro, el mensaje debe de ser enviado al servidor y ser este el responsable de la entrega del mensaje al otro cliente.

La pega está en que tenemos que tener todos los clientes (normalmente con un demonio), consultando cada x tiempo se hay mensajes nuevos para el usuario en curso.

Esta es una problemática bastante discutida en aplicaciones de todo el tipo, pues existe un consumo considerable de ancho de banda y en dispositivos moviles de bateria.

Por eso se ha creado la tecnologia "PUSH", el push consiste en que el cliente abra una conexion contra el servidor, y esta no se cierra, o sea se deja en espera. De esta manera es posible enviar mensajes instantaneos (tiempo real) a un cliente sin usar demasiado ancho de banda y sin consumo excesivo de bateria.

El problema es que esta tecnologia es dificil de implementar por diversos factores externos, como por ejemplo, si una conexión de internet esta en activo más de x tiempo el proprio proveedor de internet te la cierra, por lo que es necesario de tantos en tantos minutos hacer lo que llaman un "keep alive" que basicamente es renovar la conexion para que no caduque.

Ahora usar esta tecnologia con velneo, solo es posible usando software externo al próprio velneo, pues dudo mucho que velneo soporte conexiones abertas (pero nunca lo he intentado).

Yo estoy usando uno de esos softwares para notificaciones a dispositivos android, y funciona fenomenal.

7

Pero si los puestos no están en LAN siempre tendrás el mismo problema, y si no es por le router, puede ser por un firewall.

Como comenta velavisual, si los distintos clientes, se conectan a un mismo vServer, siempre será mejor tener un timer cada 5 segundos, que un puerto abierto en escucha (que se procesa cada menos tiempo, y consumirías más recursos).

Estando los clientes en WAN tendrías también la opción de montarte un vServer con funciones remotas que trabajen sobre una tabla, y lo usas como consulta para saber si existen mensajes, y en ese vServer, guardas una tabla de mensajes teniendo en cuenta el "De:" y el "Para:" para filtrar en cada cliente qué mensajes tiene que revisar. Sigues necesitando un timer, pero puedes usarlo en WAN teniendo que preocuparte sólo del puerto de ese vServer.

Un saludo.

8

Tal como comenta Guiseppe:
.
.
Podemos tener (el que pueda, claro) un vServer en un ordenador distinto al de las aplicaciones y que sólo actúe a modo
de intercambiador de mensajes entre vServers orígenes y destinos mediante funciones remotas.
.
.
¿Os imáginais un vServer en la Nube sólo para esta tarea?
¿No habeis pensado en un vServer N1 para hacer las pruebas?
.
saludos

9

Pues al final, viendo que no tenía fácil solución lo del TCP he montado el sistema de mensajería en un rato: mi sorpresa es que en V7 parece que los timer van mucho más finos porque no paran la escritura del usuario como sí pasaba en V6, con lo que la necesidad va a quedar muy bien resuelta.

Muchas gracias a todos por vuestras aportaciones y vamos a ver qué sorpresas nos trae la 7.8