RE: hub compliance - dropping ports

[Kevin Hawkins]

Hi Kieran, welcome !



> -----Original Message-----
> From: Broadfoot, Kieran J
> Sent: 27 August 2003 08:01
> Subject: [xAP_developer] hub compliance - dropping ports
>
>
> Guys,
>
> A quick question regarding the hub protocol in the spec. It states:
>
> "If no heartbeat is received from a given xAPp for two heartbeat
> intervals,
> then the hub-port is removed from the list."
>
> Ive been writing a hub in perl (well you get hub functionality for
free
> when
> you use the perl xAP module)

Just to clarify.. Are you saying that you are using an existing hub
alongside a xAP Perl application - or that the Perl xAP application is
effectively acting as a hub for you and indeed any other xAP application
that may be running on the same PC. If the latter then you could I guess
handle this 'in your own way' for the Perl xAP's couldn't you ?


but as Im lazy and Id like to avoid
> forking (or
> ropey old perl threads) my heartbeats are sent as and when the module
> can.
> This means the hub can never guarantee that two messages should have
> arrived
> in a particular timeframe and conclude that its safe to drop a port.

In the heartbeat message a name/value pair is sent that tells the network
how frequently heartbeats will be sent by this xAP application. This is a
value in seconds and I guess is typically 60 (every minute). It could be a
very large value too though. For a hub to drop port forwarding for a
particular xAP as you say it has to miss 2 heartbeats - so the typical time
would be 2 mins before it does drop it. What value you put in your
heartbeat
interval effects how long the hub will retain your connection. Given you
are
not predictably sending heartbeats at this interval wouldn't you just be
able to put a large value here and surprise the hub with more frequent
updates than expected. Is there not some time at which you are confident a
heartbeat will manage to be sent ?? To initially trigger a hub you probably
need one at launch.

Heartbeats are used by the network as well to know that xAp applications
are
healthy and present - and so can be sent data or expected to provide it (if
for example they were reporting events - say someone coming up your drive -
then the fact you didn't see an event but the heartbeats were arriving
gives
you significant confidence that an event has not been lost. Likewise in an
unconfirmed delivery situation instructing a device to do something and
then
seeing the next heartbeat is comforting.

Lastly Heartbeats are (going to be) used by some of the connectors that
make
the 'central controllers' aware of devices. So a controller application eg
HomeSeer sees a heartbeat and then is able to introduce that device into
the
HomeSeer model. Really this is a great way as individual I/O on a device
may
not become visible for some time if it doesn't change state. It introduces
a
device using it's schema btw. This is really neat and is being pioneered by
James.

>
> I guess my question is simple, is it essential for a hub to drop ports
> after
> a given period of time when the cost of continuing to publish to a
> specific
> port is inconsequential in real terms.

Hmm - well I guess not strictly so but.....let's look at the downsides from
the hub perspective...

1) The port remains allocated - there's a shedload of them - no real
problem
2) The resources used by the program may increase a little
(cpu/memory) - again I don't think this is an issue.
3) If the hub has any failure reporting ( a hub would be a natural
place for this) then it will not be able to flag the loss of the xAP
involved.
4) The hub will create extra local traffic forwarding to a non
existent xAPp but as this is on the loopback interface I believe it does
not
appear on the network. Note that some VB implementations of hubs and
applications can not use the loopback connector and actually use the main
Ethernet interface for all traffic. But this is not the correct way to do
it
- it happens because of an apparent deficiency in the Winsock
implementation
that causes instability.
5) We decrease the response of the network to lost xAP applications
- currently we are allowed to lose 1 Hertbeat as long as we get the next.
6) As (and if) we move to optional sequencing of data packets are
there other issues involved ??

Overall - not a big issue I agree - I guess 2 was arbitrary based on
achieving a fast response hub - Patrick are there other issues here ??

The two issues outside the hub remain though ( the comfort that a
device has reported or not missed an instruction and the configuration
ability with controllers)

>
> Please be nice and help me avoid forking ;-)

Is it not possible to almost guarantee a heartbeat within some time limit -
a large time - that way although you may send them much more frequently
they
will not time out on a hub ?? I don't think the heartbeat value has an
upper
limit although I could be wrong. Plus - what would actually be the issue if
it did ?? The next heartbeat would reinstate the hub (albeit the port may
change). I don't know how hubs actually implement their forwarding - are
they triggered only by heartbeats or by data packets too - if the latter do
they forward the first packet they receive too or just set up the
forwarding. Stuart as a hub author maybe you can comment - if the HB sets
forward up then data before the HB would be lost and this would not be
workable.

I am hoping the large heartbeat time solves your problem - I guess we could
have a value for Heartbeat interval that said 'don't time out' but in
reality everything must time out or a hub would eventually fill. So the
large values allowed for the interval value seems the best.

BTW Is it really that awkward/unreliable to send a periodic event in Perl -
it seems a major deficiency.

Kevin