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

[Kevin Hawkins]

> -----Original Message-----
> From: Patrick Lidstone [mailto:<a
href="/group/xAP_developer/post?postID=k01irVlWywXBBf3e3OM6H2ZK6yp6eWreF2Qg-FHg3N1UmXE1wRVmPfVkZOHmp4htI8EccsbmNDjXStPWkaJt">patrick@l...</a>]
> Sent: 17 June 2003 18:41
> I've been thinking more about this, and I don't think that we can use
> positive ack for anything other than one-to-one communications.

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.

>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.
>
>
> > I tend to agree this may be best in the HB - maybe as a body part
> even ??
>
> ITYM as part of the conventional message header? I think that would
> work too (possibly better - the inclusion of a sequence number is an
> implicit indication that acking is supported, would we ever need to
> know whether acking was supported before a message was sent?).

I was meaninging a heartbeat body part actually but without giving it
consideration for whether this was sensible. Header or body - really it is
not addressing info as such but obviously later use of sequence numbers and
ack's will have to be in headers so it seems to sit best there.

I think you do have to know if a device supports ACK and NACK in advance -
for example it is no use sending a message to UKUSA.Tempsensor.hall asking
for a positive ACK if it can't send one. That was sort of why I was asking
if we needed a way to turn a devices NACKing or ACKing on and off remotely.
>
> > In
> > one of the other threads I was proposing that all devices
(capable
> of
> > transmitting &amp; receiving xAP messages MUST implement a
minimal
> status
> > response) - ie making this mandatory when they are specifically
> targeted.
>
> OK, perhaps I missed that. I would be reluctant to insist on a change
> to the protocol which insisted that every device *had* to be sender
> and receiver. Today we can stick a dumb device on the network which
> just "chatters" xAP, without the need for any recieving
capability at
> all (e.g. a simple telemetry device) - it seems a shame to throw that
> away.

Again - a slight confusion - I meant the above to read as 'any device that
is both a transmitter and a receiver' must support this - a device that is
one or the other obviously can't and there should be no requirement to make
all devices transceivers

>
> > Some network actions (housekeeping / config) for example might
say
> > put a device into a state where it will only respond to level 1
> data -
> > obtaining a devices total attention and avoiding a device getting
> > sidetracked by other broadcast data.
>
> This has a lot of potential. It could be the missing link in the
> config mechanism perhaps - that solves the Dr.John scenario of many
> devices that are installed at the same time.

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.

K