Sockets. MultiProceso

Hola Alamo:

yo ya he realizado una app como esta de la cual te puede servir lo siguiente:

1. Leer de alguna fuente (archivo de configuracion, registro o DB) una lista
de "servidores" que van a atender por los diferentes puertos, despues de
leerla levanto un hilo donde reside el proceso de escucha (listen del socket
ciclico) de cada "servidor" dinamicamente.

2. Los "servidores" pueden exponer por propiedades publicas los datos de
mensajes, bytes o usuarios conectados, asi mismo puede levantar eventos
cuando llega un mensaje y estos eventos se pueden atrapar en diferentes capas
de la aplicacion.

Sobre lo ultimo, si, un servidor escucha por un puerto y despues de aceptar
un socket entrante lo redirecciona a un nuevo puerto, esto lo hace la
implementacion de la clase socket por debajo.

Suerte pues.

Jairo P.

"Alamo" wrote:

Buenos días a todos.

Tengo una duda de implementación a ver si me podeis ayudar.

He desarrollado con .NET Visual Basic, dos aplicaciones una cliente y otra
servidora mediante el uso de sockets.

En la aplicación servidora, he creado una clase Servidor la cual es la que
se encarga de realizar todo el proceso de escucha y atención de mensajes por
parte de un cliente, todo de forma concurrente (Con suprocesos a la hora de
atender un mensaje)de forma que el servidor desde que recibe un mensaje,
este crea un subproceso para tramitar dichos mensajes, y continuar a la
escucha por mas mensajes.

La idea ahora es hacer que la aplicación servidora sea capaz de escuchar por
mas de un puerto de forma que creando multiples instancias del objeto
Servidor pueda a través del lanzamiento de subprocesos, tener tantos objetos
servidor como clientes se vayan a conectar, es decir, tantos subprocesos
servidor como clientes se quieran conectar.

En base a esta idea me surgen las siguientes dudas:

1) Como puedo hacer para que por código se cree de forma automática tantas
instancias de clase Servidor como puertos a la escucha necesite, sin
necesidad de tener que tocar código cada vez que quiera un nuevo objeto
servidor a la escucha.
2) Como puedo sincronizar los subprocesos servidor de forma que muestren en
pantalla todos los mensajes que van llegando.

He realizado pruebas de conexión de varios clientes al servidor utilizando
un único puerto, y el servidor de forma automática una vez establece la
conexión con el cliente, establece un puerto de conexión para cada cliente
diferente al puerto de escucha. Esto lo he comprobado con el comando netstat
en el servidor, con esto lo que quiero decir, es que la idea de que el
servidor siempre tenga el puerto de escucha libre para atender peticiones
¿ya se consigue de forma automática por la propia filosofía de
funcionamiento de los sockets?. Quizas mi problema sea que aún no entiendo
bien el funcionamiento de los sockets.

Por cierto he utilizado tcp orientado a la conexión.

Bueno espero haberme explicado,

Saludos,

Álamo.

Buenas tades Jportelas.

Primero darte las gracias por tu atención y contestar a mi mensaje.

Bueno al punto 1: Yo había también pensado en la forma de lanzar un hilo a
nivel de listen, lo que pasa es que por motivos de tener "Objetos
Servidores" independientes y tratarlos por separado, deseché dicha opción
pero me parece una buena idea la de hacerlo a nivel de listen dentro de la
clase servidor y además a través de un elemento externo como un archivo o
registro de una base de datos indicar el número de puertos a poner en
escucha. Lo que no se como implementar es lo siguiente:

1) Una vez sabemos la cantidad de suprocesos listen que necesitamos
arrancar, es necesario según mi implementación actual crear tantos objetos
listen del tipo socket o tcplisten de distinto nombre por cada "Servidor"
que queramos a la escucha. Claro, ¿Como implemento por código esto de forma
que cada vez que el procedimiento new de la clase servidor se ejecute, este
genere tantas variables del tipo objeto TcpListen de socket con distinto
nombre para poder ser tratados?

2) Ahora supongamos que ya tenemos conseguido el implementar la creación
de objetos con distinto nombre para cada tipo de objeto listen, ¿como puedo
implementar por código, funciones y procedimientos los cuales sean para
todos y cada uno de los suprocesos listen que hemos lanzado? es decir, si el
subproceso listen 4 que escucha por el puerto 2345 recibe un mensaje, este
lo tramite. En este caso creo (desde mi punto de vista) que lo ideal sería
tener un procedimiento o función el cual fuera general para todos los
suprocesos lanzados, y que este sea capaz de detectar a que suproceso se
refiere la funcionalidad a implementar. Esta es mi otra duda, como
implementar con .NET dicha funcionalidad.

En cuanto al punto 2, mi objeto servidor y cliente, utilizan como bien
apuntas todas las funcionalidades que describes, aportando todo lo necesario
para saber si el servidor está en marcha, quien está conectado, quien se
desconecta y cuando se reciben mensajes por parte de los clientes.

En cuanto al tercer punto que me confirmas, gracias ya que tenía esa duda.

Concluyendo, quizás mis dudas de implementación se podrían aclarar si
pudieras enviarme alguna porción de código en la que se encuentre
implementado los dos puntos que te comento en el párrafo inicial. Si quieres
te puedo enviar mi código y si puedes, quieres y tienes tiempo, me enseñas
un pequeño ejemplo de como implementar tu idea. Te estaré muy agradecido.

Saludos y Gracias,

Álamo.





"Jportelas" escribió en el mensaje
news:

Hola Alamo:

yo ya he realizado una app como esta de la cual te puede servir lo

siguiente:

1. Leer de alguna fuente (archivo de configuracion, registro o DB) una

lista

de "servidores" que van a atender por los diferentes puertos, despues de
leerla levanto un hilo donde reside el proceso de escucha (listen del

socket

ciclico) de cada "servidor" dinamicamente.

2. Los "servidores" pueden exponer por propiedades publicas los datos de
mensajes, bytes o usuarios conectados, asi mismo puede levantar eventos
cuando llega un mensaje y estos eventos se pueden atrapar en diferentes

capas

de la aplicacion.

Sobre lo ultimo, si, un servidor escucha por un puerto y despues de

aceptar

un socket entrante lo redirecciona a un nuevo puerto, esto lo hace la
implementacion de la clase socket por debajo.

Suerte pues.

Jairo P.

"Alamo" wrote:

> Buenos días a todos.
>
> Tengo una duda de implementación a ver si me podeis ayudar.
>
> He desarrollado con .NET Visual Basic, dos aplicaciones una cliente y

otra

> servidora mediante el uso de sockets.
>
> En la aplicación servidora, he creado una clase Servidor la cual es la

que

> se encarga de realizar todo el proceso de escucha y atención de mensajes

por

> parte de un cliente, todo de forma concurrente (Con suprocesos a la hora

de

> atender un mensaje)de forma que el servidor desde que recibe un mensaje,
> este crea un subproceso para tramitar dichos mensajes, y continuar a la
> escucha por mas mensajes.
>
> La idea ahora es hacer que la aplicación servidora sea capaz de escuchar

por

> mas de un puerto de forma que creando multiples instancias del objeto
> Servidor pueda a través del lanzamiento de subprocesos, tener tantos

objetos

> servidor como clientes se vayan a conectar, es decir, tantos subprocesos
> servidor como clientes se quieran conectar.
>
> En base a esta idea me surgen las siguientes dudas:
>
> 1) Como puedo hacer para que por código se cree de forma automática

tantas

> instancias de clase Servidor como puertos a la escucha necesite, sin
> necesidad de tener que tocar código cada vez que quiera un nuevo objeto
> servidor a la escucha.
> 2) Como puedo sincronizar los subprocesos servidor de forma que muestren

en

> pantalla todos los mensajes que van llegando.
>
> He realizado pruebas de conexión de varios clientes al servidor

utilizando

> un único puerto, y el servidor de forma automática una vez establece la
> conexión con el cliente, establece un puerto de conexión para cada

cliente

> diferente al puerto de escucha. Esto lo he comprobado con el comando

netstat

> en el servidor, con esto lo que quiero decir, es que la idea de que el
> servidor siempre tenga el puerto de escucha libre para atender

peticiones

> ¿ya se consigue de forma automática por la propia filosofía de
> funcionamiento de los sockets?. Quizas mi problema sea que aún no

entiendo

> bien el funcionamiento de los sockets.
>
> Por cierto he utilizado tcp orientado a la conexión.
>
> Bueno espero haberme explicado,
>
> Saludos,
>
> Álamo.
>
>
>