Ticket #6183 (in-band bytestreams filetransfers on XMPP)

[Marcus Lundblad]

tis 2008-07-01 klockan 13:40 -0600 skrev Peter Saint-Andre:
> Marcus Lundblad wrote:
> > FYI
> > 
> > I've started on support for using XEP-0047 (IBB) as a fallback method
> > for file transfers on XMPP.
> > Right now it almost works as a "standalone" method (ie. when disabling
> > support for socks5), it can complete a file transfer when everything
> > goes well. 
> 
> Great!
> 
> > It doesn't quite yet handle cancellation.
> > Also it can't yet "take over" when socks5 bytestreams fail.
> 
> It's not fully clear to me what you mean by cancellation and takeover. 
> Could you clarify? I want to make sure the protocol addresses your concerns.
> 
By cancellation, I mean when one end cancels the transfer. Currently the
sender doesn't correctly cancel the callback that is registered for
<iq/>:s used to send data when a session is destroyed, so sometimes the
initiator sends a package and get a close <iq/> from the receiver before
the response to the <iq/> that contained the data is received. In this
case the callback for the response should be unregistered when the
session IBB session is disposed, so that a generic error response is
sent.

And "take over", I meant the scenario where setting up a socks5
bytestream fails, it should automatically revert to setting an IBB
session for the transfer. Currently my implementation doesn't handle
that case. This should of course only be attempted if the receiver
replies with both "http://jabber.org/protocol/bytestreams" and
"http://jabber.org/protocol/ibb" as methods available for file
transfers.

One thing that just occured to me is that perhaps it would be a good
idea to "remember" which method worked for a particular JID, perhaps
within a login session. F.ex. if socks5 was attempted and failed and IBB
was used as a fallback, then if that same JID made another file transfer
offer during the same login, it will just present IBB as a possible
transfer method, since it would be likly socks5 would fail again, this
could avoid waiting for a timeout to occur. It is probably good to reset
this at next login, since firewall configurations could have changed,
f.ex.

//Marcus

> > And it is not exactly a speed deemon :)
> 
> No, it's not. But it's intended to be the method of last resort. :)
> 
> /psa
>