[jdev] File Transfer Interoperability

[Justin Karneges]

On Wednesday 08 August 2007 12:22 am, Sergei Golovan wrote:
> On 8/8/07, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> wrote:
> > 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.
>
> Any other file transfer method requires opening a socket by the
> receiving party. If the socket can't be opened then the stream is
> obviously invalid. IBB lacks this part, and I think it would be good
> to add it. It would make a file transfer working essentially the same
> regardless of the SI method used.

If the sender offers a file and then cancels it before the receiver accepts, 
then S5B hasn't even started yet.  In other words, the sender hasn't sent the 
iq-set for the S5B open.  Therefore, there are no sockets to time out, and 
the receiver will wait forever.  Just like with IBB, just like with anything.  
It's an SI issue.

If the sender cancels the file transfer immediately after the receiver 
accepts, then there is a chance that the sender may have started an IBB or 
S5B negotiation.  This is much less common than the SI problem, and I think a 
timeout in IBB here would be enough to solve this situation of bad luck.

FWIW, S5B also doesn't specify any timeouts.  If the receiver goes offline 
instead of replying with an iq, then the sender will wait forever (and this 
is the case today with Psi).  As you can see, endlessly waiting is not a 
feature of just IBB.  We generally don't specify timeouts in XEPs.  For 
example, how long should you wait for a vcard request to be answered?  Today, 
all of these possible timeouts are left to implementations to decide.

-Justin