[JDEV] Dialup and laptop users, lost packets, and faulty presence info

[David Waite]

I would recommend a heartbeat which instead does what clients have done 
for a while - sends a whitespace character in-between XML packets. You 
would need to modify the client connection piece to do this 
(c2s/jadc2s/jpoll/dpsm/whatever); but it would be significantly less 
intrusive to a client than a separate component sending new XML 
elements. Rather than having the clients reply to this message, their 
TCP/IP stack will just ACK the new packet. Failure will result in the 
stack of the server recognising the socket as dead, which will be 
treated just like a (clean) disconnect is now.

-David Waite

Nathan Sharp wrote:

> I've been pretty successfully running a 1.4.2 jabber server at our 
> offices for a short while now and love having IM internal to our 
> company w/o the big players.  I've got one major issue, though.  I've 
> been trying to find past debates over this but have failed so far, so 
> excuse me if this has already been discussed.  The problem comes when 
> a dialup or a laptop user pulls the plug on their network connection 
> without ever logging off of jabber.  The jabber server won't notice 
> until it tries to send a message to the client and gets a network 
> error.  Unfortunately this is unreliable as is.  I've had users that I 
> know are offline stay listed as online for as long as 12 hours!  To 
> make matters much worse, when you send a message to a person in this 
> state, you never get an error back telling you that your message 
> failed to be delivered, although usually you can tell becuase the 
> server will soon afterwards log the faulty connection off and the 
> person will dissapear from your roster.
>
> Personally I think the only possible way to deal with this is to have 
> a heartbeat between the client/server (I'd be willing to bet that all 
> the major IM systems do this, because they don't exhibit this 
> problem). Temas expressed some concern over scalability, but to me 
> this problem is worth fixing at a small cost to scalability.  (In 
> fact, it may help some because you will not have non-existent users 
> taking up resources!)
>
> Now, I'm willing to spend a small amount of time at least prototyping 
> a solution for testing, although given all my other projects I don't 
> have a lot of time.  So far, however, I've had a terribly frustrating 
> time trying to gather enough documentation or sample code to even 
> start. What I've been trying to do is build a server component w/ 
> jabberbeans (I'm fond of Java, but I could go with other solutions if 
> they are better...) that would send out a packet to all online users 
> once per configurable time period, and then kick off anyone it doesn't 
> hear a reply from before the next heartbeat.  Ideally it could listen 
> for messages and presence info from clients and skip a heartbeat if 
> other messages have been received from the client during that 
> heartbeat period, although I'm not clear if a component can listen 
> globally like that or not. 
> What I've got so far is a server component which runs and lists itself 
> in the client's browser, but I'm pretty stuck past there because I've 
> failed to find documentation on server components past that point (or 
> even example server components).  In specific:
> 1a) Can I register with the server and have it send me presence 
> information globally for everyone without having to have users 
> explicitly register with me?
>  - OR -
> 1b) If not I figure I can just query for all online users right when 
> it comes time to send out the heartbeat, which I found how to do last 
> night with an iq:browse to servername/admin.  However, jabberbeans 
> doesn't have a ExtensionBuilder for that namespace.  Is there a way w/ 
> jabberbeans to send custom xml or do I have to write my own 
> ExtensionBuilder?
>
> 2) Can I globally listen to <message> packets coming from users 
> without disturbing the normal delivery process?
> 3) I can always send a client version or time IQ to the client as a 
> dummy packet for my heartbeat, but ideally I want the smallest message 
> possible to which clients will respond to without any user 
> intervention or knowledge.  (Sounds like a prime place for a JEP if 
> this works out). Does anyone have ideas on a particular message type 
> to send?
>
> I have more questions, but I haven't researched them yet, so I'll wait. 
> Thanks!
>   Nathan
>
>