[jdev] File Transfer Interoperability

[Justin Karneges]

On Tuesday 07 August 2007 10:29 pm, Sergei Golovan wrote:
> On 8/8/07, Peter Saint-Andre <stpeter at jabber.org> wrote:
> > 3. IBB (XEP-0047) is a great fallback if all else fails.
>
> IBB couldn't be a great fallback. It's very inconvenient to use in the
> fillowing circumstances (which don't so rarely happen):
>
> 1) JID A offers file to JID B and waits for the answer (note that to
> answer, B must return an IQ result, and the time interval might be
> quite long).
>
> 2) JID A decides to abort file transfer and closes the
> file-transfer-window-or-whatever-GUI-she-has.
>
> 3) JID B replies with IQ result, but
>         a) File transfer doesn't start (A aborted it)
>         b) JID B will NEVER know about A aborted file transfer and
> will stuck with file-receiving-GUI forever since there's no mechanism
> to recognize this unwilling to transfer.
>
> Wouldn't it better to add an extra query from B to A after stream
> negotiation part? If A doesn't want to send file anymore, she will
> return error to B.

I wouldn't put this at the IBB level.  A negotiation timeout will work well 
enough there.

The problem you speak of, which does indeed happen a lot, has more to do with 
the SI exchange.  If someone offers a file, and you take too long to accept, 
they may cancel the file offer and you'll never know.  This will happen 
regardless of whether you use S5B or IBB or anything.

In Psi we solved this by adding a timeout to the accept phase.  The sender 
must begin the S5B negotiation within 30 seconds of the receiver 
pressing "Accept".  If the timeout expires, a dialog is presented to the 
receiver that says something along the lines of "the sender probably 
cancelled".

I believe Jive added a protocol extension so that the receiver can know if a 
file transfer was cancelled.  Maybe it is worth documenting.

-Justin