Re: [JDEV] Status Notifications.

[qbradley@csc.UVic.CA]

I think it would be a good idea to develop a protocol for notifications
that allows different servers to make different decisions about CPU time,
bandwidth, etc...

Here is a try:

Server A wants to know when the status of user "fred" on server B changes.
Server A sends a message to server B letting server B know this.  Server B
sends messages to server A when status changes.  (the connection between A
and B could be a continuous connection with occassional traffic, just like
between the client and the server)

Now servers have options

One server has lots of bandwidth but a heavily loaded CPU.  It doesn't
want to think much.  Any time a server notifies interest in a user, the
server adds the interested server to a list.  any time any users status
changes, the server sends the notification to every server on the list.

This is terribly wasteful of bandwidth but uses almost no memory and very
little CPU..

Another server is more concerned with bandwidth and is willing to expend
more memory and CPU to concerve bandwidth.  This server keeps a list of
users for each server interested in status changes.  Each time a users
status change, the server looks at each server in its list, and sends a
notification only if that server has indicated an interest in the user
whose status has changed.

Servers should be able to send other messages to each other, such as "I'm
not interested in anyone from you anymore" or "I'm not interested in user
X anymore" (which might be ignored by some servers).

I think this solution is better than polling, even in the wasteful case,
because messages are only sent when something has changed.  The potential
waste comes from servers that send messages about users a server doesn't
care about.  If that became a problem, servers could be configured not to
accept notifications from "noisy" servers... this would cause pressure on
such servers to use a different module.. but only if it was enough of a
problem that they got on ignore lists.  Note that not receiving
notifications would not prevent messages from going back and forth.

Lets get some servers up and running and try out some of these options.

Quetzalcoatl Bradley
qbradley@csc.uvic.ca