Re: Re: Lost /duplicated messages

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

barrygordon wrote:

>Thanks for the reply.  I resolved the problem.  I had to put pacing
>logic into the multipart messages.  After the first part is sent the
>transmitter waits for a message acking that part and then sends the
>next part.  This is working correctly for the stage of testing I am at
-
> Single "transmitter", "Single receiver", but I
have all the logic in
>to handle multiple transmitter/receivers.  The application is a
"many
>to one".  The many are in wall touch screens, the one is actually
>homeseer.
>
>
This shouldn't be necessary but if it works for you then 'mission
accomplished' ;-) ...   if the scenario is always many to one then TCP
is maybe a better choice I would have thought.  xAP uses UDP as it
requires one to many.

>A touchscreen can request Homeseer to run a script which returns a
>result (e.g. get the current weather for a given zip code.)
>
Are you using the xAP HomeSeer plugin then ?? or I think your own
receiver and HS interface - you never mentioned what language you were
writing your code in, just interested.

> The result
>may be on the order of 2000-5000 bytes, hence the need for multi part.
>Also had to encode the text to remove carriage returns (chr(13)) and
>Line feeds (chr(10)).  Since on PC's they always come as CRLF, each
>CRLF is replaced by "~" before transmission, and returned to
CRLF after
>received.
>
>
Just a pointer here - the characterset allowable in a parameter value is
printable ascii - there shouldn't be any other characters there and
indeed some hubs could (correctly) block such messages . The real
'guaranteed to always break it' is the LF  CHR(10). xAP doesn't support
character escaping or substitution but has an ability to support all
characters if necessary by using the ! rather than = delimiter .  Values
should be coded as uppercase ASCII coded hex (see the spec for some more
info on this).  However this will cause a doubling of your message size
so is not ideal in your scenario.  If your apps are just talking to each
other then this may not be such an issue and indeed could be done in a
bespoke way (not to xAP spec) but it would be wise to take the data 'out
of band' to xAP eg by using another port or TCP or something. You should
not send 'not to spec' xAP packets as it could cause issues to some
receivers, if you intend at some time to release your application to
others this is critical - although of course what you choose to do on
your own intranet is your choice, it just may cause other apps/hubs not
to function.

>I now have a new problem that I am going to start a new posting on.
>Perhaps you will be able to assist me with that.
>
>

Ask away...

K