Re: Proposal / RFC: Change xAP wire format

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

I must also say that, after years of use of xAP in very different
applications, I see xAP as a protocol specially suited for:

- Gateways (embedded or not)
- IP-capable embedded devices with an important amount of IO's (ie: Netiom
xAP)
- PC applications


--- In xAP_developer@xxxxxxx, "Neil Wrightson" <neilw@...>
wrote:
>
> My two cents worth,
>
>
>
> 1.       Personally I think all embedded devices should be slaves.
That is,
> they are controlled by a separate master host controller (App on a
PC). They
> do not make decisions on their own. They only respond to packets
directly
> sent to them. Trying to listen to every incoming packet and compare
this
> against an action list uses a lot of resources. Then add a means of
editing
> this list from a remote location, takes up even more resources on the
> embedded device.
>
>
>
> 2.       In regard to embedded Ethernet devices, I have made quite a
few
> (AVR Mega32..XMega128) and they still struggle with the requirements
of the
> xAP message size overhead.
> A smaller version of the protocol would also be useful here.
> Could the two protocols exist on the same network but with say a
different
> port address (say 5000). I realise this opens another can of worms ie
we
> already have a port internationally assigned to us. Another thing
required
> would be an additional gateway app on a PC. Separate standalone app or
part
> of the xAP hub service. On this gateway, it reads all 3639 traffic and
only
> sends through packets destined for a device present in a manually
created IP
> lookup list, and/or created by the embedded heartbeat. Any packets 
received
> from port 5000 would be sent back to the main xAP port.
>
>
>
> 3.       In regard to the serial version, ie RS485. A similar thing
could
> happen to the above embedded Ethernet version. The xAP gateway would
filter
> based on a lookup list and only send packets to the RS485 devices with
a
> matching address.
>
>
>
> 4.       A similar thing could carry through to Wireless devices
(Something
> I plan on making in the near future)
>
>
>
> 5.       My issue is that, I'm good with embedded hardware and
firmware but
> have no idea where to start with making a new HUB or gateway with the
above
> modifications.
> I used to windows program in Delphi (Pascal) and have some knowledge
of C
> and basic but that's it. No idea on how to even compile an existing
xAP app.
>
>
>
> A sample command to an embedded device. Don't care what version, how
many
> hops, what class, where it came from. If you're sending it to me, you
should
> know what I am and capable of.
>
> {
> Dest=FF123400
> }
> {
> OP1=ON
> }
>
> {
> OP2=ON
> }
>
> #13         Always nice to have an end of message delimiter.
>
>
>
>
>
> The heartbeat and status could be similar, same for BSC.
>
>
>
> Regards,
>
> Neil Wrightson   (Australia).
>
>
>
>
>
> From: xAP_developer@xxxxxxx [mailto:xAP_developer@xxxxxxx]
> On Behalf Of Kevin Hawkins
> Sent: Thursday, 1 December 2011 6:38 AM
> To: xAP_developer@xxxxxxx
> Subject: Re: [xAP_developer] Re: Proposal / RFC: Change xAP wire
format
>
>
>
>
>
> Actually there have been several implementations of xAP on low
bandwidth
> networks but I agree it's not ideal / the most compact protocol, human
> readability precludes it. The lower the bus speed and the higher the
> traffic the bigger the problem. There are a host of really compact
> alternative protocols but they of course sacrifice some of xAP's
> features like readability , wildcard addressing etc. If your bus is
> part of a wider bandwidth xAP topology eg Ethernet and it is an 'end
of
> the road' in terms of xAP traffic then you do have options to minimise
> bandwidth.
>
> You could for example :
>
> Tokenise or even 'drop' some of the xAP parameter names .
>
> Implement a bridge that filters traffic such that only relevant
packets
> are passed onto the low bandwidth segment.
>
> In your bridge you could bi-directionally map longer source names to
> shortform addresses - but your bridge would have to manage wildcard
> matching. Wildcard matchingwithin the low speed segment wouldn't be
> impacted.
>
> Using these techniques you can get a very satisfactory implementation
> whilst retaining interoperability with other xAP devices on say
> Ethernet. IIRC both Patrick and Lehane have implemented xAP over
RS-485.
>
> If you are totally standalone then you could use significantly
compacted
> source addresses and not use wildcarding at all, plus tokenise / omit
> parameters. It's really only when you're bridging into a wider world
> and need interoperability that you need to be careful and then you can
> implement a lot of smarts in the bridge. OTOH if you are totally
> standalone and low bandwidth then I am not sure xAP is a sensible
> choice...or what advantage it would offer, or why you would consider
it
> anyway.... !
>
> JSON really offers no benefit for low speed devices so it's a bit of a
> red herring in that respect. What's good is that embedded devices are
> becoming faster, larger in capacity and lower in cost so this is a
> diminishing problem... It would be neat to be able to implement xAP
> on a $5 device though.
>
> K
>
> On 30/11/2011 18:25, Daniel Berenguer wrote:
> > Hi Alan,
> >
> > Having myself integrated xAP (BSC) on several computing
platforms, I must
> say that xAP is maybe not the most compact protocol for very
constrained
> uC's. On the other hand, even if xAP wanted to be network-agnostic,
the fact
> is that xAP is specially suited for IP networks. I'd never recommend
the use
> of xAP on RS485 buses for example (this is my personal opinion). As
result,
> people is usually adding xAP capabilities on IP-capable uC's only.
This
> said, IP-capable platforms usually have the necessary resources to run
a
> basic xAP stack without problems so adding JSON or not shouldn't be an
> issue.
> >
> > Daniel.
> >
> >
> >
> > --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>
,
> "hillbillies@"<hillbillies@> wrote:
> >> Hi Patrick,
> >>
> >> I know that this is an old thread but I have been thinking
about posting
> on this for a little while. Having been woken up at 4:11 this morning
by an
> aftershock (that's what happens when you live in Christchurch, NZ!)
I've had
> plenty of time to put my ideas together. I'm new to xAP, only been
playing
> around for a couple of months on AVR devices and I don't have a full
system
> running yet.
> >> I don't want to put down any of the ideas of those that have
been in the
> project for a long time, but I think that I can put forward some ideas
from
> a different perspective.
> >>
> >> Background:
> >> I wanted to monitor my power meter to look at energy
consumption. If I
> was putting some wires in for that I might as well have a play with
home
> automation. I looked around and liked the ideas of xAP, specifically
that is
> was non-centralised and it was agnostic of processor and network. It
is nice
> that a fair amount of work has been put into Linux app which I wanted
to
> use.
> >> I decided to go with the idea of putting the full xAP message
over an
> RS485 2 wire link using J1708 style circuitry. Over the last month
I've put
> together a library for the AVR for carrier sense multiple access with
> collision detection. I wanted a low power network (which is why I
didn't go
> for ethernet) and to keep things simple. The idea for putting the full
xAP
> message over the network (rather than the BAZ485 idea) was that it is
just
> an extension of the UDP network, rather than a load of sensors
attached to
> the PC.
> >>
> >> So coming from an embedded point of view I would like to put
forward some
> points on your idea for a wire format change:
> >>
> >> On the main front page of the xAP website it says:
> >>
> >> -Simple, easy to implement/retrofit
> >> -Suitable for use with a wide range of processing
capabilities, from
> embedded controllers to fully fledged PC's
> >> -Operating system agnostic
> >> -Programming language agnostic
> >> -Network agnostic
> >>
> >> Where to you see xAP going?
> >>
> >> From what I can see most of the development has gone into PC
centric UDP
> messaging applications. I'm coming from a different point of view, the
> embedded world.
> >>
> >> What I do like is the human readable message, I've got to say
that it's
> helped me alot in my development. However in the embedded world with
the
> lack of RAM and processing cycles the passing of redundant data is a
waste.
> >> If you look at the JSON protocol there can be white spaces
and plenty of
> double-quote symbols. What's the point of sending this information?
It's OK
> in a UDP packet on a PC. But if you want to be network agnostic then
you
> need to cater for lower bandwidths. I would be in favor of taking the
> existing 'source=' and turning it into 's='. We know what source is
> mandatory, it's got to be there, the 'ource' is redundant data.
> >>
> >> By reducing the amount of data sent across the link you are
benefiting
> from:
> >> - Less RAM used to hold it while processing
> >> - Reduced processing time to decode the packet
> >> - Less time on the physical network (therefore increase the
number of
> packets you can put across)
> >>
> >> As I said before, where does the group see xAP going. If it
wants to move
> forward in the lower power, lower speed embedded world then maybe JSON
is
> not the right way to go?
> >> If xAP's future is x86/ARM then it's not a problem, but I
guess that the
> protocol has to suit the lowest common denominator. A high speed
processor
> can cope with JSON or any other protocol that is thrown at it, a low
spec
> processor can only cope with simple things.
> >>
> >> What are other peoples views on this - I'm ready to be shot
down.
> >> Like I said earlier, I'm new to xAP and I want to thank
people for their
> development efforts. I'm not trying to push my thoughts, just airing
them in
> public.
> >>
> >> Cheers
> >>
> >> Alan
> >>
> >> --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>
, "patricklidstone"<patrick@>
> wrote:
> >>> I would like to propose a fundamental change to xAP -
adopting JSON
> notation for the wireformat. JSON (RFC4627 /
> http://en.wikipedia.org/wiki/JSON
/ json.org for further details) is now an
> established standard, with wide cross-platform and cross-language
support.
> >>>
> >>> A wide array of parsers are available off-the-shelf. It
is very similar
> to the existing wireformat, which pre-dates JSON, and the JSON
manifesto
> incorporates many of the design aims of the original format (such as
XML
> being too complex/too fat for optimal use on embedded devices).
> >>>
> >>> Whilst retrofitting support to existing apps would be
slightly painful,
> the fact that most libraries and frameworks abstract the parsing, and
that
> there are inherent similarities, wouldn't make the switch too bad from
a
> developer perspective, and that burden is outweighed by the adoption
of a
> standard IMO.
> >>>
> >>> Thoughts?
> >>>
> >>> Patrick
> >>>
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>




------------------------------------