On 06/11/2008 11:54 AM, Justin Karneges wrote: > On Wednesday 11 June 2008 07:09:24 Peter Saint-Andre wrote: >> On 06/11/2008 6:53 AM, Fabio Forno wrote: >>> On Tue, Jun 10, 2008 at 11:40 PM, Peter Saint-Andre <[EMAIL PROTECTED]> > wrote: >>>> Yes, the idea behind XEP-0234 is that IBB will be the file transfer >>>> method of last resort, but that it will always work (for some value of >>>> "always"). >>> Some sort of "always", correct. The worst case scenario with IBB is >>> ending with an unusable connection if the server starts throttling >>> packets, thing I bet will happen as soon as IBB becomes widespread. In >>> Bruxelles we discussed about the possibility of sending an early >>> warning to the client with a packet from the server asking to limit >>> the rate. This is far better then a fixed bitrate, since it allows >>> severs to dynamically allocate bandwidth accordingly to actual usage. >> So the server would determine if you are close to hitting some rate or >> bandwidth limit and will tell you to slow down? What if the bottleneck >> is between the recipient's server and the recipient's client (e.g., I am >> on a fat pipe and you are on a mobile connection)? Then perhaps it is >> the recipient's client that would want to tell the sender's client to >> slow down. > > My plan has always been to use XEP-198 for this. If your server wants you to > back off, it'll just not ack back to you over the c2s (or s2s) link. > Similarly, a mobile client that is dying would just not ack back to the > server. This way you can do flow control per-hop rather than end-to-end.
Erk, yes, I need to finish those revisions to XEP-0198 -- it's in a sad state of semi-modification right now. But it's slowly moving up my GTD list. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
