[standards-jig] IBB: Making it all "go"
daniel at chote.net
Thu Apr 10 00:36:06 UTC 2003
Ok, im here for my late addition to this thread and sorry *joy*, I
havent read all the messages yet, so I apologise if some of these points
have been touched apon..
In theory... if all servers were operating 100%, and clients were smart,
using messages wouldnt be too much of a problem. But as it stands... it
would be would not be worth the hassle... Honestly..
The possibility of these packets ending up in offline storage. This has
a very high possibility of happening...
* Latency from s2s connections on presence broadcast
* Presence not even being recieved on disconnect (seen this happen many
times with the jabber.com server)
* Unclean socket termination from the other party.. still showing online.
* 2 client resources connected, 1 goes offline, and the other starts
recieving the stream (what if thats a cell phone??). Remember the
latency between s2s... remember it well!
Now, i know that if the server implementations worked properly, other
than the offline storage issue from the s2s latency, it would be
reasonable.. but, still very irrelevant to the definition of the
Stepping in to another realm.
The thing i dont like about this whole idea is, when does a client know
how much data is too much, and at what rate to broadcast, if it doesnt
have some sort of ack... Jabber servers have different karma settings,
some high, some low... a client has no ability to be able to find this
information out... all of a sudden there is a lack of reception at the
other end of the stream, and then what do we do???
I dunno if <message/> is at all a viable solution..
Dave Smith wrote:
> ----- Original Message -----
> From: "Richard Dobson" <richard at dobson-i.net>
> To: <standards-jig at jabber.org>
> Sent: Tuesday, April 08, 2003 5:26 PM
> Subject: Re: [standards-jig] IBB: Making it all "go"
>>Also what about using a jabber:x:expire of a few minutes on the message
>>packets to make sure they wont get stored for too long.
>>But I do see the problem of easier denial of service if message packets
>>are used in this manor to transfer the data rather than iq, i.e.
>>sending lots and lots of packets that get stored offline and then when
>>they are delivered to the user could hold up their connection for ages
>>or maybe even cause a karma problem (does karma affect the direction of
>>server to client?).
> Well, this is a more general problem with offline storage -- anyone could do
> this DoS, regardless if they were using the IBB protocol. So it doesn't
> really make anything "easier". The only way to really deal with this problem
> would be to make offline storage work with a POP/IMAP style interface
> instead of always flushing every message. From a protocol standpoint, we
> could certainly dictate that the IBB protocol MUST close the stream if the
> recipient party becomes unavailable. That doesn't really fix anything, but
> does provide some strong suggestions to thwart unintentional DoS -- of
> course, what "real" DoS'er would follow something that's merely a
> convention? :)
> Bottom line, I think we simply establish a convention in the JEP whereby the
> IBB system SHOULD/MUST close the stream when the target party goes offline.
> Of note, karma is only an inbound restrictor, never outbound. The server
> sends packets as quickly as possible to the client.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Developer/Designer and typical drunk!
email/jabber: daniel at chote.net
More information about the Standards