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