Re: Lost /duplicated messages

["barrygordon" <barry@xxxxxxxxxxxxxxx>]

--- In xAP_developer@xxxxxxx, Kevin Hawkins <lists@u...>
wrote:
> 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

********************************************************************
My solution on the non sendable charachters was to "depart from the
spec" (but not in a way that would hurt other apps). Prior to sending
raw text with embedded CR LF charachters I encode the block by
changing all CRLF sequences (they will always appear as that dublet)
to the single ascii Charachter "~" which has the ascii code
ordinal
of 126 and ergo is legal in the spec. After reception of the blocks
and reassembly of the text message I decode the text changing things
back. In my application there are no other funny charachters.  It
solves my problem.  I consider the encoder/decoder as part of the App.