[JDEV] Status Notifications.

qbradley at csc.UVic.CA qbradley at csc.UVic.CA
Fri Jan 15 11:50:20 CST 1999


Here is a fourth option.

The roster is stored in a file on the server.  When the client conencts to
the server, the server sends it back to the client.  The client keeps the
roster in memory, and periodically sends messages asking the server if the
users are online.

This is the same as you describe in that the roster is not stored in the
runtime memory of the server.  However, as us poor abused ICQ users know,
it is a serious pain to store the roster locally.  This is because your
roster doesn't follow you when you log into ICQ from different places.
For example, from home, from work, from the conference you are attending,
etc...  It would be super wonderful to have one roster no matter where you
connect.

Quetzalcoatl Bradley
qbradley at csc.uvic.ca

On Fri, 15 Jan 1999, Aron Atkins wrote:

> i would recommend against keeping the "roster" on the server side.
> 
> for those of you who don't like analysis problems, just believe me.
> 
> assuming the "roster" is on the server side, here's the reason:
> 
>   1. servers must keep a list of currently logged-in users.
>      assuming N users logged at one time, the server must maintain
>      N records.
>   2. servers maintain a "roster" for each user logged in.
>      at worst, each user will have each other user in their roster.
>      this means that the total roster list could approach N^2.
>      this will be very bad in large installations.
> 
> if we can keep memory linear, we'll be in much better shape. higher-order
> polynomials are bad.
> 
> if we move the storage and maintainance of the rosters to the clients,
> we have a maximum of N records on the server and N records on the client.
> the records on the client do not add memory, since they are already
> necessary.
> 
> if we keep the rosters on the clients, this does require that a client
> occasionally poll servers to determine the status of roster-members,
> but this is only a small bit of traffic, and could be piggy-backed on
> some other transmission.
> 
> of course, the transmission is more expensive than the other way, but this
> seems like a managable tradeoff.
> 
> aron
> -- 
>  aron atkins                                 (atkins@{chrysalis.com,wpi.edu})
>  * j a d e d *               <A HREF="http://www.gweep.net/~jaded/">jaded</A>
> 
> 
> 

Quetzalcoatl Bradley
qbradley at csc.uvic.ca




More information about the JDev mailing list