[JDEV] Status Notifications.

[Nicholas M. Kirsch]

What about the case where a client is unpredicatably disconnected (ie
no-carrier, lost route)? Status messages are no longer received from that
client.. So will there be timers on the other clients, or will there be
keepalives involved?

On a security sense, I would feel more comfortable with most of the 
communication between my client and the Jabber server.. Otherwise I can
tell the IP address of all of my 'buddies' and boom.. unless there were
plans to have messages be sent directly? I didn't think that was part of
the protocol...


Not that I have a better alternative, yet.. 

Nick
nkirsch at biznatch.nick.org

 On Mon, 18 Jan 1999,
Donovan Schulteis wrote:

> 
> >> 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.
> >
> >Expecting the clients to poll for people on your roster is going to
> >become very expensive very quickly.  Presence indication is one of the
> >most important features I think, and having built and used a system
> >where I am notified *immediately* when someone arrives I find this vastly
> >preferable.
> 
> 
> Why not have the server store your roster list in your account (thus
> allowing user/computer roaming), and when the user opens the client and
> connects to their particular server, have the roster list downloaded from
> the server to the client.  The server could then check to see who on that
> roster is online at the time the connection is made and download that info
> to the client (Either with the roster, or right after downloading it).
> After that the server does no more checking.
> 
> When users connect to the server, a status is sent out to all persons in
> their roster saying that the user has come online. This should be done by
> the server at the same time that the roster is checked to see who is online
> (above para).  After that, the client of each individual user could then
> post all status messages to the server, AND all users listed in the roster.
> That way, no traffic will be passed between clients and servers (after the
> session loading) except when a user changes their own status or when actual
> messages are being passed.  This way the client applications keep track of
> who is online (and whatever other status needs), and relieves the server of
> that responsibility.
> 
> In essence, the server would send the initial online message to the roster,
> and then the client would receive all status messages from a buddys client,
> and broadcast all further status messages to all buddies, ignoring any
> bounced messages (if the client was to send to all buddies, instead of just
> online buddies).   You have the server announce your presence and let you
> know who is online, and then the client app accepts the status message
> responsibilities from there.
> 
> The status messages would be sent just as any other instant message would be
> sent, but the intended receiver would be the client, not the user.  The
> client would then display the corresponding buddy status as necessary.
> Any new buddies added during that session could be uploaded to the server at
> the time of adding or when closing the session, updating the users
> account/roster file.
> 
> This makes the client a little smarter than some have originally conceived
> it to be, but I feel that this scheme is necessary to reduce the load on the
> server greatly.  The server is already handling a great deal for each
> individual user via multiple transports and message passing.  Give the
> server a break  :)     Anyways, the idea is to get multiple, everyday ISPs
> to adopt and implement this server, and they absolutely will not if it is
> going to eat up processes and CPU time.
> 
> I dont know, what do you all think???
> Deej
> 
>