[JDEV] Heartbeat patch for dialup and laptop users and faulty presence info

Wed May 29 13:11:36 CDT 2002

<sarcasm type='mild'>
<stream:stream 
  to='schumacher at jdev' 
  xmlns='jabber:client' 
  xmlns:stream='http://etherx.jabber.org/streams'>
<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 at 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 at 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 [mailto:ben-jdev at blahr.com] 
> Sent: Wednesday, May 29, 2002 10:28 AM
> To: jdev at 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 at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 

**********************************************************************
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.
**********************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20020529/ec5e031b/attachment-0002.htm>