Hola Carlos, gracias por la respuesta. Estoy viendo los links.

La aplicacion cliente que tengo ahora ya tiene implementado un thread para
recibir los mensajes del Servidor. Para el envío de mensajes, utilizo un
timer que se repite cada x segundos. Esto lo hago asi porque necesito hacer
una cola de espera con las peticiones de mi cliente al servidor, de manera
que solo haya una petición a la vez..

Utilizo un objeto tcpclient y ya cambié de utilizar streamwriter y
streamreader a Networkstream para mandar la informacion como arreglos de
bytes.

La primera duda que tengo es con la cuestión de, si utilizar métodos
sincronos o asincronos. Hasta ahorita no he usado métodos asincronos porque
requiero esperar la respuesta del servidor forzosamente para poder continuar
con el procesamiento en mi programa. Un caso simple de lo que hago es que
mando una solicitud de eco y tengo que esperar a que el servidor me regrese
el mensaje para poder continuar. Mientras mi programa espera por la
respuesta, no tengo necesidad de hacer otras cosas. ¿En este tipo de
escenario es conveniente mantenerme con métodos síncronos?

Por otro lado. Como comentaba en mi mensaje anterior, yo solo tengo que
implementar el cliente. No sé cómo esté implementado el servidor. No sé en
qué lenguaje esté desarrollado, tampoco sé cómo es que tiene implementado el
envio y recepción de mensajes (si usan streams, networkstreams, si envian y
reciben las cadenas de texto o los arreglos de bytes, en una sola
instrucción o de uno en uno).
El hecho de implementar métodos sincronos o asincronos en el cliente ¿lo
determina en mayor o menor medida la manera en que estén implementados los
métodos en el servidor?

¿Tengo que saber de antemano como envia y recibe datos el servidor? O bien,
mientras haya información en el stream, ¿da igual cómo se acceda a esa
información? Es decir, si el servidor me mandase la información de un byte a
la vez, y yo uso el método read del networstream ¿eso no ocasiona problemas?

Todo esto lo pregunto porque sospecho que podría estar relacionado con el
hecho de que puedo enviar mensajes pero no veo lo que me mandan. En mi
entorno de pruebas, como yo desarrolle tanto el cliente como el simulador
del servidor, todo funciona muy bien, pero nada más me conecté al servidor,
y empezó el problema

De cualquier manera, hablaré con la gente que tiene levantado el servidor
para ver si pueden y/o quieren platicarme algunos detalles de su
implementación.

Te agradecería infinitamente si pudieses comentar algo de todo esto que me
inquieta.

¡Gracias!
El 29 de junio de 2009 18:42, Carlos Peix <peix-lis...@praxia.com.ar>escribió:

>  Hola Marcel,
>
> Lo primero que me surge decirte es que vas a tener que dedicar un buen
> tiempo a aprender sobre threads, sockets, metodos asincronicos y demas temas
> relacionados. No es facil implementar comunicacion por sockets solida.
>
> Luego, mas que ayudarte con tu consulta, te refiero estos articulos que a
> mi me sirvieron bastante.
>
> // Asynchronous Client Socket Example
> // http://msdn2.microsoft.com/en-us/library/bew39x2a(VS.71).aspx
>
> // Using an Asynchronous Client Socket
> // http://msdn2.microsoft.com/en-us/library/bbx2eya8(VS.71).aspx
> // Asynchronous Server Socket Example
> // http://msdn2.microsoft.com/en-us/library/fx6588te(VS.71).aspx
>
> // Using an Asynchronous Server Socket
> // http://msdn2.microsoft.com/en-us/library/5w7b7x5f(VS.71).aspx
>
> // http://www.csharphelp.com/archives3/archive486.html
>
>
> Hay dos maneras de implementar lo que vos queres hacer, una de mas alto
> nivel usando TcpClient y TCPListener y otra usando Socket directamente. Yo
> cai en la segunda porque la primera me limitaba y no era eficiende con
> trafico elevado.
>
> Suerte
>
>  *Carlos Peix*
>
>  ------------------------------
> *De:* puntonet@mug.org.ar [mailto:punto...@mug.org.ar] *En nombre de *Marcel
> Felix
> *Enviado el:* Lunes, 29 de Junio de 2009 08:32 p.m.
> *Para:* puntonet@mug.org.ar
> *Asunto:* [puntonet] TcpClient envío y recepcion de mensajes
>
>   Hola a todos.
>
> Les platico el problema.
>
> Tengo una aplicación de consola hecha en c# que funciona como cliente de un
> Servidor remoto el cual no tengo idea de cómo esté programado, pero sé que
> recibe peticiones en un puerto de un socket.
>
> Mi aplicación al iniciar crea un objeto tcpClient que abre una conexión con
> el servidor y envía como mensajes cadenas de texto plano. Hasta aqui no hay
> problema. Mando mi mensaje y el servidor lo recibe. El envío de mensajes lo
> hago a través de un streamwriter, mediante una función que se llama
> EnviarMensaje :
>
>  StreamWriter sw;
>  sw =  new streamWriter(tcpClient.getStream());
>  sw.WriteLine(mensaje)
>  sw.flush();
>
>
> Para la recepción de los mensajes que me manda el servidor, he creado un
> streamReader que lee los datos del mismo stream del tcpClient. Algo como;
>
> StreamReader sr;
> sr =  new StreamReader(tclClient.getStream());
> string respuesta =  sw.ReadLine();
>
> El envío de mensajes funciona ok. El problema es que no recibo los mensajes
> que me manda el servidor. La recepción de mensajes del servidor se hace en
> un thread que dentro de un ciclo while (mientras esté conectado), debe
> guardar en un string lo que obtenga de sr.ReadLine();
>
> Esta aplicación funciona bien en mi entorno de desarrollo, junto con una
> aplicación de prueba que hice para simular al servidor real al que tengo que
> conectarme. El problema surgió ahora que ya tuve que conectarme al servidor
> real. Recibe mis mensajes pero mi aplicación no recibe los del servidor.
> Parece que nunca se cumple la condición while(conected)
>
> ¿cómo es posible que todo funcione sin problemas en mi entorno y no reciba
> nada cuando intento comunicación con el servidor real?
> Un detalle es que sí recibí las respuestas del servidor, pero solo hasta
> que la aplicación del servidor se cerró,
>
> ¿No es correcto que use el mismo tcpclient para leer y escribir del Stream?
>
> ¿Tendría que tener en mi aplicación cliente un tcpListener para recibir los
> mensajes? Pero si así fuera, no tendría que funcionar tampoco en mi entorno
> de prueba  ¿o si? ¿y por que funcionaría solo cuando la aplicación remota se
> cierra?
>
> Gracias de antemano.
>
>

Responder a