Re: Topic 4: Point to point acknowledgement in xAP messages

[Patrick Lidstone]

> I was thinking that positive ACK was very important here - for
example
> initially you send out a message requiring positive ACK targeted at
> UKUSA.*.> that tells me immediately what devices are responding to
that
> filter. If only neg ack was available then if a device received the
message
> it needn't respond - although I accept there could be a higher
level policy
> that forced responses. Plus if a device missed a packet it doesn't
actually
> know it has until the next packet is sent (when the sequence number
jumps
> one). Let me give it some more thought but I sort of like leaving
the
> flexibility of both.

Discovering devices, is, I think a separate issue? What happens if a
new device joins a pack scenario later, in any case? The sender will
then start receiving acks from a device it doesn't know about...

There are major network loading concerns that also need to be
addressed: if I target ">", every device on the network will
potentially respond to a pack message! Ethernet might be able to cope
(although I doubt it), but serial will collapse under the strain
without a doubt.

It is true that nack based sequencing needs a steady flow of
messages. Perhaps we could append the last nack sequence number to
the heartbeat to ensure that? This then imposes a limit on the number
of simultaneous nack sessions a device can handle (since we would
want one sequence number per nack session and the hb is a finite
size), but it may be an acceptable compromise, given that it is only
an issue for target based addressing? Supporting something like 4 or
8 concurrent targeted nack sessions would be ok I think? If HB
frequency is increased, these could instead be rotated, so that each
successive hb indicates the nack seq number for a different nack
session in an endless cycle.

> >That
> > would be the situation where we used a non-wildcarded target
address.
> > Is that special case worth specifying a +ve ack for alone?
> >
> > Using a -ve ack works much, much better in the many-to-many
> > environment, because it prevents network meltdown.
> >
> > > Which sort of leads on to a retry type problem - if you did
ask say
> > all you
> > > relays to pulse on for 1 sec but one device missed it - we
may need
> > a way of
> > > resending it such that devices that already had done this
didn't do
> > it
> > > again. A sort of retry/transaction identifier.
> >
> > Receivers who heard the retransmitted message would simply
discard it
> > because the sequence number would be less than the expected
next
> > match. Does this address your scenario or have I misunderstood?
>
> Maybe - again I'll think on it - you're proposing issuing several
packets
> with the same sequence number - essentially a repeat - there might
be an
> issue of a device that doesn't support sequencing interpreting it
twice (eg
> a caller display device logging a second call)- a workaround would
be to
> take retries to another protocol that differed from the first eg
changing
> something in the header, maybe class.retry or something - or even
using
> major and minor sequence numbers.

If a receiver has to distinguish class.retry, then surely it can
remember the last received message seq no, even if it doesn't fully
support acking? Stating the obvious, I can see two situations in
which problems could arise: situations in which the message window
size is >1 (retransmission of an old message supercedes a later
message. e.g. msg1=device on, msg2=device off, retranmsg1=device on --
a non-ackaware device will turn the device on again). The other
situation is where the message contents themselves are statefull,
e.g. msg1="press power button" , msg2="press power
button",
retranmsg="press power button". The retransmitted message, if
acted
on, results in the device entering the incorrect state.

> Again - a slight confusion - [snip] there should be no requirement
to make
> all devices transceivers

Good!


> In a way it could be used to move network comms to a higher level
too - for
> example putting a network into a state where only devices that have
level 2
> or above messages can send - this shuts the whole network up for
critical
> maintenance/config - perhaps all unconfigured devices sit on level
99 for
> example and you silence all devices except level 99 to find what's
there -
> when configured you move it to 98 as a holding area (partly
configured has
> uid but awaiting source info) and then later into a general level 9
and
> below. My aboves and bellows are confusd but you get the idea -
maybe this
> is another non related topic.

Agreed, this needs a topic of its own.

Patrick