<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12"> <TITLE>RE: [JDEV] Heartbeat patch for dialup and laptop users and faulty presence info</TITLE> </HEAD> <BODY> <sarcasm type='mild'> <stream:stream   to='schumacher@jdev'   xmlns='jabber:client'   xmlns:stream='<A HREF="http://etherx.jabber.org/streams'" TARGET="_blank">http://etherx.jabber.org/streams'</A>> <iq id='A0' type='get'>   <query xmlns='jabber:iq:register'/> </iq> <iq id='A1' type='set'>   <query xmlns='jabber:iq:register'>     <username>felix</username>     <password>mypass</password>     <name>Felix Gallo</name>     <email>felix-reply@jdev</email>   </query> </iq> <iq id='A2' type='get'>   <query xmlns='jabber:iq:auth'>     <username>felix</username>   </query> </iq> <iq id='A3' type='set'>   <query xmlns='jabber:iq:auth'>     <username>felix</username>     <resource>reply-to-jdev</resource>     <password>mypass</password>   </query> </iq> <presence/> <message to='schumacher@jdev'>   <body>You're completely right -- a few bytes every few minutes would be intolerable for all those low bandwidth users.  The finely tuned bandwidth efficient jabber protocol would be brought, yea, to its very knees!</body> </message> </stream> </sarcasm> I personally like the idea of guaranteed message delivery as an end around this problem, although it seems clear that ping/pong or Ben's register-a-timeout method would work out ok. Another poster couldn't figure out how to get guaranteed message delivery to work, but it's actually pretty simple: 1.  User sends guaranteed message, with checksum, retry count, and what-to-do-if-it-gets-stuck. 2.  Server receives message, verifies that it's OK. 3.  Server optionally passes it on to any intermediate servers, handshaking to make sure that the message is received before deleting it from local store. 4.  If the message is received successfully by the next server in the chain, the delivery responsibility passes to that next server, and the local server deletes it. 5.  If the message can't be passed to the intermediate server, the what-to-do-if-it-gets-stuck field is examined (possible values might include delete-with-notification, retry-for-a-certain- number-of-times, etc.) 6.  Upon receipt, you're done. Note that this was guaranteed message delivery, rather than return-receipt.  With return-receipt, you just have the recipient fire off a guaranteed message back declaring success.  Just never have return receipts require return receipts.. ;)   > -----Original Message----- > From: Ben Schumacher [<A HREF="mailto:ben-jdev@blahr.com">mailto:ben-jdev@blahr.com</A>] > Sent: Wednesday, May 29, 2002 10:28 AM > To: jdev@jabber.org > Subject: Re: [JDEV] Heartbeat patch for dialup and laptop > users and faulty presence info > > > On Wed, 29 May 2002, Nathan Sharp wrote: > > While all this is good discussion, the fact remains that as jabber > > currently stands, it often reports users as online for hours after > > they are not online, and FAILS TO DELIVER packages or to > return an error when > > users are in this state.   I would make the point that one > of the main > > reasons I switched from ICQ to Jabber was that ICQ started loosing > > messages now and then.  When I discovered that Jabber did > the same, I > > was quite dissapointed, although w/ Jabber I stand a chance > of fixing > > it since it is open source. > >   [...snip...] > > > The biggest argument I've heard so far is that ping/pongs > would take > > too much bandwidth.  If your end users would prefer very > slightly less > > bandwidth used yet LOST MESSAGES AND FAULTY PRESENCE info, > well, you > > got different users than mine. > >   [...snip...] > > It seems to me that you are trying to solve this issue in the > wrong way. If you want guaranteed message delivery, then the > protocol will have to be adjusted to have clients send > notification when a message is delivered (like > return-receipts in email, but hopefully more intelligent). In > fact, I would argue that guaranteed message delivery should > be the responsibility of the client rather than the server. > Modifiying the server to provide this functionality brings up > the question of "what is the appropriate behavior if a > message isn't deliver?" Should the server put the message in > offline storage? Bounce an error message? What happens if > offline storage isn't configured on the receiving party's server? > > On the other hand, I do agree that faulty presence is an > issue. I hate messaging people and then realize that they > aren't actually online. My only goal is that we keep this > discussion focused. You will *NOT* solve lost message issues > with a ping/pong solution, however, you might be able to > provide better presence reliability. > > That being said, I'm afraid that I'd have to side with Dave > Waite on this issue, I don't think ping/pong is a good > solution (or even your existing ping solution), especially > when you consider that wireless clients are likely to have > some of the most pronounced connectivity issues and highest > costs of bandwidth. A better solution should be proposed as a > protocol change, perhaps as a negotiated timeout period where > a client tells the server upon logging in that if it doesn't > send data within a given amount of time, then the server > should consider it unavailable. > > My $0.02. > > bs. > > _______________________________________________ > jdev mailing list > jdev@jabber.org > <A HREF="http://mailman.jabber.org/listinfo/jdev" TARGET="_blank">http://mailman.jabber.org/listinfo/jdev</A> > <CODE> ********************************************************************** E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. ********************************************************************** </CODE> </BODY> </HTML>