A Few Remarks
It's important to remember that Gubcast clients are uniquely identified by
the TCP ports they listen for messages on (actually, by the combination
of Internet address and port number) - not by client name. Client name
is really the one clue that your Web page can give your Gubcast server to
tell it how and when to push content out to the user. There are no
constraints on the syntax of client name and no explicit length limit, so
feel free to encode within client name whatever context information will
be useful to the server.
While we think Gubcast is a handy tool for Web application development, it's
not magic. There are things it can't do:
Firewalls
Gubcast can't penetrate firewalls without help. If there's a firewall
between the Gubcast server (your application) and the user's browser, it
must be directed to let TCP traffic pass on the clientPort and
serverPort numbers cited in the HTML containing the applet.
Otherwise Gubcast will be unable to register with the server and content
push will be impossible.
For this reason, and because Gubcast requires installation of the Java
plug-in on every user's machine, Gubcast may turn out to be especially
useful for applications running within corporate intranets - behind the
firewall - as opposed to those that run over the Internet at large.
Browser crashes
Gubcast can't tell when a browser simply crashes (i.e., the machine the
browser is running on is abruptly reset, powered off, unplugged, vaporized
in a nuclear holocaust, etc.). When this happens, the Gubcast applet
isn't given an opportunity to unregister with the server, so a "ghost"
client may remain in the server's client registry; in the Gubdemo system
this means that a ghost client is left in the Gubshell client menu. This
is unfortunate but unavoidable, and it's easy to repair: the ghost will be
immediately detected and deleted if you try to push content to it.