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

[Peter Saint-Andre]

Marcus Lundblad wrote:
> 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.

Right. I don't know how well any clients handle that right now but I'd 
be happy to ask around.

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

True. We've tried to handle that fallback case in the upcoming Jingle 
file transfer approach:

http://www.xmpp.org/extensions/xep-0234.html

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

Yes I think it makes a lot of sense to cache that within a session.

Peter