Cola de Mensajes/Procesos

26/09/2008 - 12:07 por jesusR | Informe spam
Hola, les presento la siguiente situación:
Tengo desarrollada una clase (DrvMgr) que se encarga de codificar
cierta información(a traves de un método llamado CodificaComando) y
enviarla a un dispositivo conectado en el puerto serie (a traves de su
método llamado EnviarDato). el dispositivo retorna un comando por el
mismo puerto Serie.

Luego tengo una aplicacion windows que utiliza esta clase para el
envio de estos mensajes.

El problema esta en que requiero hacer una "cola" de mensajes, es
decir, tengo que evitar que sean enviados N mensajes "en el mismo
momento" al dispositivo.
Por ejemplo, la aplicacion de windows realiza lo siguiente:
DrvMgr dm = new DrvMgr();
for (int i = 0; i < 300; i += 1)
{
string comando=dm.CodificaComando(i);
dm.EnviarDato(comando);
System.Threading.Thread.Sleep(2000);
}
en donde dm es la instancia a mi clase que codificará la info y la
envia al puerto COM. BuscaComando codifica y devuelve una cadena de
alrededor de 10 Kb, y por ultimo EnviarDato es el método que enviará
la cadena al dispositivo a través del puerto Serie (COM).

Actualmente incluyo en el código de envío la siguiente instrucción:
System.Threading.Thread.Sleep(2000); esto para evitar que tanto el
puerto del PC como del dispositivo se saturen.

La idea es realmente ir metiendo los mensajes en una cola e irlos
sacando después que el dispositivo emita una respuesta.
Me imagino que sera haciendo algo tipo cola o algo así.

Algún comentario?

Preguntas similare

Leer las respuestas

#6 RFOG
29/09/2008 - 16:51 | Informe spam
Jesús, según yo lo hago:

Un genérico Qeue en el que cada elemento es un array de bytes (cada array
será el comando que estés enviando a la impresora). Un hilo inserta, el
otro saca mientras queden y se va a dormir cuando esté vacía. El que
inserta, en cada inserción envía un evento al que saca cada vez que meta
para que si está durmiendo se despierte y listo. Una sección crítica sobre
la lista para que no haya inserciones a medio sacar y viceversa. Como es
un reader/un writer no hay problema alguno si usas una sección crítica.

Yo lo hago así en C++ y va como una moto, tanto con impresoras como
sockets, protocolos más o menos complejos, etc.

On Mon, 29 Sep 2008 09:24:54 +0200, jesusR wrote:

On 26 sep, 14:53, wrote:
On 26 sep, 07:07, jesusR wrote:

> Algún comentario?

Lo que necesitas es mantener ambos dispositivos sincronizados.
Funcionando a la misma tasa. Una cola no sirve para eso. Su propósito
es evitar la pérdida de data ante un congestionamiento del momento.

Si los dispositivos no están sincronizados, vas a tener una cola
siempre vacía o infinitamente llena. Si tu dispositivo no puede
procesar esa cantidad de data, ninguna cola lo ayudará... me parece.



Tanto el dispositivo como el el puerto del Pc estan configurados a la
misma velocidad, asi que por ese sentido jamas perdere data. La cola
la creo para enviar mensaje a mensaje. MAs a detalle, los dispositivos
son impresoras termicas, al cual se les envia cadenas codificadas con
lo que se desea imprimir.
cada mensaje es un documento que ha de imprimir. Lo que quiero evitar
con la cola es enviar un lote de documentos y el buffer de recepcion
de la impresora se llegue a saturar, por lo cual meto todos los
mensajes en cola, y a medida que la impresora responde (dando un ok de
impresion) envio un nuevo documento.
Que por que no uso los drivers propios de la impresora y las clases
propias de impresion de .NET? Por requerimientos de desarrollo.






Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
El que sabe no habla, el que habla no sabe.
Respuesta Responder a este mensaje
#7 jesusR
30/09/2008 - 15:41 | Informe spam
Gracias a todos por sus respuestas!.
Tema encaminado y en proceso de resolución.

On 29 sep, 16:51, RFOG wrote:
Jesús, según yo lo hago:

Un genérico Qeue en el que cada elemento es un array de bytes (cada array  
será el comando que estés enviando a la impresora). Un hilo inserta, el  
otro saca mientras queden y se va a dormir cuando esté vacía. El que  
inserta, en cada inserción envía un evento al que saca cada vez que meta  
para que si está durmiendo se despierte y listo. Una sección crítica sobre  
la lista para que no haya inserciones a medio sacar y viceversa. Como es  
un reader/un writer no hay problema alguno si usas una sección crítica.

Yo lo hago así en C++ y va como una moto, tanto con impresoras como  
sockets, protocolos más o menos complejos, etc.



On Mon, 29 Sep 2008 09:24:54 +0200, jesusR wrote:
> On 26 sep, 14:53, wrote:
>> On 26 sep, 07:07, jesusR wrote:

>> > Algún comentario?

>> Lo que necesitas es mantener ambos dispositivos sincronizados.
>> Funcionando a la misma tasa. Una cola no sirve para eso. Su propósito
>> es evitar la pérdida de data ante un congestionamiento del momento.

>> Si los dispositivos no están sincronizados, vas a tener una cola
>> siempre vacía o infinitamente llena. Si tu dispositivo no puede
>> procesar esa cantidad de data, ninguna cola lo ayudará... me parece.

> Tanto el dispositivo como el el puerto del Pc estan configurados a la
> misma velocidad, asi que por ese sentido jamas perdere data. La cola
> la creo para enviar mensaje a mensaje. MAs a detalle, los dispositivos
> son impresoras termicas, al cual se les envia cadenas codificadas con
> lo que se desea imprimir.
> cada mensaje es un documento que ha de imprimir. Lo que quiero evitar
> con la cola es enviar un lote de documentos y el buffer de recepcion
> de la impresora se llegue a saturar, por lo cual meto todos los
> mensajes en cola, y a medida que la impresora responde (dando un ok de
> impresion) envio un nuevo documento.
> Que por que no uso los drivers propios de la impresora y las clases
> propias de impresion de .NET? Por requerimientos de desarrollo.

Microsoft Visual C++ MVP
==> Mi blog sobre programación:http://geeks.ms/blogs/rfog
Momentos Leves:http://momentosleves.blogspot.com/
Cosas mías:http://rfog.blogsome.com/
Libros, ciencia ficción y  programación
> El que sabe no habla, el que habla no sabe.
                -- Lao Tse. (Siglo VI a.C.) Filósofo chino. Fundador del taoismo.
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida