mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charlie Youakim <charlie.youa...@gmail.com>
Subject Does XMPP truly handle presence?
Date Mon, 14 Mar 2011 19:19:12 GMT
Hello Users,

I hope I'm doing this correctly.  I'm a new user and I've never done an
email to a listserve like this.

I’m emailing the group because I actually have an observation and a question
about XMPP and Vysper.  I’m new to XMPP. Very new. I’ve been looking and
testing with it for the last couple of days. My problem is that I don’t feel
like the “Presence” portion of the protocol works all that great, at least
on my initial tests with Openfire and ejabberd2. If I work as normal, sure,
it works perfectly. But, I was a bit harder on it. First I killed my
internet connection by disabling wifi through my OS(I tested it in Linux and
Windows). XMPP still worked on every test in this manner. That’s GREAT!

The problem was with my next test. I decided to kill my wifi radio by
disabling it through hardware. Here’s where I couldn’t get XMPP’s Presence
to work. The user on this machine always stayed online, despite the wifi
radio being killed through hardware.  Every time this was tested on my
Android phone (pulling the battery), or on my laptop (killing the radio),
the XMPP server would fail to recognize the disconnection and the user would
stay online.

This is something I’ve noticed in G-Chat as well. On a user’s computer
crash, or power loss, some users can just hang there online.

My question to users:  Can XMPP handle this case for Presence detection? It
seems to me that it can’t, which worries me.  Can Vysper handle this?

Thanks for any input.  I'm interested to hear opinions from experts in the
area of XMPP.

(As a side note I turned on the ping service and was able to detect the
disconnect, but it seems strange to me that I should require an addon to
handle presence detection, when the protocol has the idea of Presence in its
title.)

-Charlie

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message