[standards-jig] JEP-0047 (IBB) Updated
thoutbeckers at splendo.com
Tue Apr 8 17:57:27 UTC 2003
"Peter Millard" <me at pgmillard.com> wrote on 8-4-2003 16:42:03:
>Tijl Houtbeckers wrote:
>> However, I still think usage of <iq/>'s for acking can *optionally*
>> provide a somewhat decent and very simple flowrate control. (Because
>> flowrate is one part of TCP we'll eventually have to re-invent for
>> some applications).
>Why do we need flow-rate control for these packets. An answer of "to
>bypass karma" is not valid. (Since we should NOT be defining protocol
>where one of the requirements is that it should be possibly to bypass
>a psuedo-security measure).
If you want a "stream" you'll need flowrate control. Else you'll just
turn Jabber into a gigantic store and forward server. Every stream
needs flowrate control, a lot of streams use TCP for this. We can't do
this with Jabber because our TCP stream stops at the server.
Suppose I have a 10-mbit connection to my Jabber server and you are on
14k4 dailup. I initiate my "stream" to you and among the many other
things I do with my account I start sending one packet after the other
to you. I have no way of telling when or if you have received them, so
they just "pile up" on the Jabber server, and keep coming to you till
you disconnect or the server's storage runs out.
As you see I'm talking about a situation without karma here (in fact,
in this simple case karma would probably help a bit with the situation).
I doubt I would even call this kind of behaviour a "stream".
Software Engineer @ Splendo
More information about the Standards