RE: Message Queuing

["Sullivan, Glenn" <gsullivan@xxxxxxxxxxxxxx>]

Glad I'm not the only one that's stumbled upon this...

I believe I have gotten it to be as fast as possible at re-queuing the
messages into my own queue.

As a guideline, what do people recommend for a throttled rate?  I.e., if
I have a glut of messages to dispatch, how long should I pause in
between each one?

There is the potential for hundreds of one-wire devices on a network, so
I'll probably want to deal with this in my handling of
1wire.request.devicelist messages.

Speaking of: is there an official 1-wire schema?  I am currently
starting with/planning to expand the one used by Stuart Grimshaw and
described here:
http://tinyurl.com/82e6m

But I'm also seen mention of a HomeSeer plug-in that links 1-wire temp
sensors to HS via xAP... I haven't fully investigated the schema used by
that program yet.


Glenn Sullivan, MCSE+I  MCDBA
David Clark Company Inc.
-----Original Message-----
From: xAP_developer@xxxxxxx
[mailto:xAP_developer@xxxxxxx]
On Behalf Of Patrick Lidstone
(Personal E-mail)
Sent: Monday, June 27, 2005 8:11 AM
To: xAP_developer@xxxxxxx
Subject: RE: [xAP_developer] Message Queuing

> 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