Re: xPL Hubs

["David Amphlett" <dave_yahoo@xxxxxxxxxxxx>]

Ugly or not it's there, and is a single point of failure for all
listeners on one machine. My primary reason for monitoring in the hub
is for reliability / maintenance. I want to know that the hubs on
various machines are up and responsive. It would also be useful to
track the number of messages the hub thinks it has received as, when
compared over time with other messages, this would highlight lost
datagrams and enable analysis of where they were lost.

The connectionless nature of udp makes it difficult to determine
simply from the presence of a listener that a hub is active, but
futhermore something listening doesn't mean something functioning.
Seeing logging / statistics / or heartbeats tick is the only sure way
to know everything's tickety-boo.

None of this is a big issue with a couple of PC's in your own house,
but if you want to sell installations at a high premium it's nice to
be able to have some ability to diagnose problems quickly and
possibly remotely (via VPN).

I've considered asking that the hubs themselves send out heartbeats,
and this would go quite some way to satisfying my requirements, but
I'd still be happiest with all the logging being pulled together with
syslogd/windows eventlog.

--- In ukha_xpl@xxxxxxx, Tom Van den Panhuyzen <tomvdp@g...>
wrote:
> So much focus on that hub!  :-)
> It's ugly.  It shouldn't be there.  It should be hidden completely.
>
> The hub's only purpose is to distribute incoming packages from port
3865 to  any
> xpl apps  active on  the pc.   It could  have been  implemented
using a complete
> other  mechanism  of  inter-process  communication  than  via
broadcasting  UDP
> packages.  For  me  it  is  part  of  the  communication  layer,
it  is  not an
> application.
>
> It would be cool to have monitors available via perfmon,
webservices, mmc,  etc.
> But I  am not  sure the  hub is  the best  place where  you would
plug these in.
> Wouldn't a monitor be an  xpl app like any other,  making use of
the same  inter
> -process communication as all the other apps ?
>
> I would like to  see the mechanism for  hub-enabling "on" by
default.   It makes
> perfect sense to me that when an xpl app comes up, that it starts a
hub if there
> is none.  It should be clear from the documentation that comes with
the app that
> it is  hub-enabled.  In  fact, the  reverse is  true: every  app
that is not hub
> -enabled should clearly indicate that it  will not work without an
explicit  hub
> or without a hub-enabled app.
>
> Why do some apps already  provide a hub ?  Because  they do not
want to  trouble
> the user,  I suppose.   The only  way to  make this  even more
transparant is by
> pushing developers to hub-enable their apps.
>
> That a newly installed app stops your old hub because after a
reboot it couldn't
> grab the port is a good thing: it means you have a new shiny hub
and you can get
> rid of the old rusty one :-)
>
> Agreed that a user must be able to disable the hub for whatever
reason that user
> has...
>
> There may be issues with  cross-platform compatibilities.  If you
want  the same
> architecture  on  another  platform  (i.e.  something  called
xpllib  providing
> communication facilities)  and you  want it  to behave  the same,
then maybe we
> should opt for the lowest common denominator and not include hub
functionality.
>
> I admit that  I am not  on this list  long enough to  see the big
architectural
> picture. The modifications I  made to xpllib were  driven by a
direct  need: the
> multiple IP issues,  security on an  internet connected pc,
missing elements in
> xpllib, integrating the hub into xpllib to solve a dependency
issue, etc.  While
> I was  working on  this I  thought most  people would  use (or
move to)  a .net
> development environment  as this  xpllib is  targeted at  that
environment and I
> have  not  seen an  xpllib  that was  not  targeting .net.  So  I
thought  these
> modification would benefit the community as a whole.  But if there
is  a big mix
> of platforms and technologies then that is not the case.
>
> Regards,
> Tom