Re: hub compliance - dropping ports

[Stuart Booth]

On Wed, 27 Aug 2003 11:41:18 +0100, "Kevin Hawkins"
<<a
href="/group/xAP_developer/post?postID=jvo3z2NtH5s6vswA-84aSf4tEW-64DH-h8rrztnLt_g3q0GxvyB3OhfERTX8NYva67fGykYvjff7btjMuO4">lists@u...</a>>
wrote:

>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.

That's a cunning engineering solution if ever I saw one!

>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.

In my solution that first h/b is critical, as it contains the port
number that the hub client is listening on. Without it nothing gets
sent on to the hub client until it arrives.

I don't believe I have an upper limit on the length of time b/w h/b's
other than the size of the variable that I use to store the value.

My hub generates a number of events for the application written to use
the HubListener class. These include hub client connection, hub client
disconnection (no h/b's in the prescribed (2 * h/b interval)
period-ish), and hub client renewal (when another h/b arrives before
it gets timed out.

If the hub client doesn't send a h/b in the prerequisite time period
my hub will 'disconnect' it. Assuming it doesn't manually go hunting
down a brand new port for itself in the meantime, it will get
reconnected on the same port when it eventually does send a h/b
message.

I do this all the time in my testing. Initiate hub, start up a client
application, find a bug stop it, restart it moments later, and the
client just carries on regardless as it just so happens to find the
old port again, as it's the first free one available. In a more
non-deterministic scenario it would simply re-register with a
different port and the hub will eventually disconnect the 'dead' port.

ALL messages are forwarded by the hub to the client, but the client
can implement different event handlers so it never hears h/b's if it
doesn't want to.

S
--
Stuart Booth
xAPFramework.net - a reusable xAP framework for .net

<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>
<a
href="/group/xAP_developer/post?postID=tBfKfgI2AlqPJb2ivaroglKblaTiXboSjWMtgSxHf_I4KBdtPif33lSi5CZ7hZJ0We34n356EQuq4PFPyAk">stuart@x...</a>