RE: Message Queuing

["Patrick Lidstone \(Personal E-mail\)" <patrick@xxxxxxxxxxxx>]

> So, I wrapped the xAP Framework.Net listener object into a
> component that just listens and queues message, it it's own,
> non-blocking thread.
> Then the main service app can read the queue at it's leisure.
>
> I'm just wondering how other people handle situations like
> this?  I figure it would affect any listening application
> that takes any time at all to process the messages it is
> listening for.  Is there a feature of xAPFramework.net that
> I'm not seeing that handles this?

What you've discovered is indeed a "xAP artifact". To build a
robust
application, you have to dequeue UDP messages as quicky as possible. If you
need to be absolutely certain that you received and actioned a message,
then
you need to adopt a request-reply model between the sender and receiver -
there is always a small, but finite, chance a message may otherwise get
lost
because UDP is not reliable, and all OS's ditch UDP packets once their
OS-level buffers are full.

Well behaved apps should also, therefore, be considerate when offloading
data onto the network - ideally throttling the transmission at startup.

In my apps, I look at the message address as early as possible, and discard
anything that is irrelevant. Relevant messages are generally queued within
the app, and then serviced independently by a queue reader. This improves
performance, and minimises the chance of a dropped message.

HTH

Patrick