Québec said:
Uh.
This is not what I was expecting. I was more like ICQ stuff, but I
dont want to rely on Icq.
Maybe an applet. Any suggestion?
A _Java_ applet (Java != JavaScript) does not make a difference here,
since it is executed *client-side*. A Java servlet will be executed
server-side but all solutions face a common basic problem: Who are you,
i.e. what host is your computer, out of millions of others, on the Internet?
There seems to be a major lack of knowledge and therefore a lack of
understanding about the workings of the Internet on your side. I hope
I can help it and clarify a few things:
The iCQ script and similar scripts work because the server knows who
you are (i.e. what host your computer is) as you are logging in with
your iCQ UIN. IOW: It resolves from from UIN/alias/screen name to
login status and *presuming* this to be the online status (one can be
online without logged in into iCQ and sorts, of course.)
This is something that can be triggered reliably *only* server-side
(no matter where the server is located, it applies to a local server, too).
For a general "I am online" script, not relying on iCQ and similar
public client-server services, to work on the Internet you need to
know your IPv4 address first which is what identifies your computer
out of other hosts. Since your IPv4 address is most certainly
dynamic, i.e. assigned using DHCP, you must either tell the script
the current IPv4 address or tell a third party about it for them to
perform name resolution (dyndns.org resolving quebec.dyndns.org, or
as John Wood pointed out, demon.co.uk resolving
www.quebec.demon.co.uk,
to your current IPv4 address, e.g.).
The transmission of the current IPv4 address to the script could be
targeted with a configuration file on the server containing this
information, overwritten each time you make an Internet connection,
using FTP or scp (FTP/S) for example. (A friend of mine does so.)
When accessing the Web page, a program (a server-side script or, as in
John Wood's example, the client's HTTP user agent itself) is executed
that (reads the configuration file and) tries to connect to the
specified host, using HTTP directly (as was described by John Wood),
ICMP requests (`ping'), `telnet' with port parameter, `nmap' aso. If
the connection fails, the program considers you to be offline, online
otherwise. Then it generates appropriate output that can be (parsed
and) rendered by a user agent and displayed to the user.
If the server-side script is to work only within an intranet, your IPv4
address is either static or DHCP provides known dynamic addresses. Thus
you can then ignore the IPv4/name resolution part since your LAN DNS
server can do the name resolution.
As you see, this is of course not a trivial problem.
PointedEars
