[Council] Resolving the file transfer debate
rob at cataclysm.cx
Thu Jul 3 23:01:45 CDT 2003
> I've been talking with Justin just now. He says the main objection that
> he and one other person have to 95+96 is the inability to fall back if
> the first method fails. Personally I don't see this as a common case
> (and I think it would be best to have one reliable mechanism for file
> transfer rather than the need for fallbacks etc.). However, I think one
> could do this in 95+96 by re-using the stream ID (thus providing a
> "link" between the original attempt and the fallback).
OK, I've just had a long discussion with Justin to try to get a sense of
what the issue is. I'll try to summarise our discussion here.
The flow he described to me is this:
- I initiate a file transfer, and offer s5b and ibb as transport
- You accept the transfer, and select s5b.
- The stream establishment fails for some reason.
- I initiate another file transfer (same metadata = same file), only
offering ibb this time.
He wants to be able to implement it such that the receiving client can
automatically accept the second FT initiation.
Now, while I personally wouldn't want to use this (if something fails,
for any reason, I like to know why), I can understand that it might be
nice for a client to fallback gracefully in this situation, so we
started to look at ways that 95/96 could be adapted to allow this.
There seems to be two issues:
- A receiving client must be able to "link" a later FT initiation with
an earlier one.
- A receiving client must know whether or not it should wait for a new
FT intiation if the previous one failed.
JEP-0041 handled the former by tying each operation to a single stream
ID, and the latter using the "keepAlive" attribute, which told the
receiving client whether to wait for a new request if the first failed
for some reason.
Now, as Peter has said above (and Justin agrees), re-using the stream ID
is enough to link multiple initations together. All that is required for
this is some extra text in JEP-0096 that makes it clear that if a
receiving client sees a stream ID that it has already seen before
(perhaps only if that one failed), then this new request can be
considered a retry. It might be worth mentioning that if the FT metadata
has changed, then the most recent should be used (or perhaps we should
just say that the behaviour is undefined. Though, if the receiver just
uses whatever metadata it last received, then it will have less state
information to maintain). This change seems relatively benign.
Without the "keepalive" flag (though "retry" would probably be a better
name for it), the receiving client will have to wait for some undefined
amount of time after an failed FT initiation to see if it receives a
retry. While not a problem for the client internally, Justin made the
point that it could result in odd behaviour in the UI (eg a progress
dialog that gets closed and "reappears" out of nowhere when the retry is
This could be added as a single attribute, or via an <x>-like extension
in another document.
Justin says he will be will be content with a FT protocol that includes
the facilities for retry. I don't know whether the "keepalive" stuff is
too controversial for the spec proper (as an extension it should be
fine), but using the stream ID to "link" streams seems like a simple
change (and doesn't even change the actual protocol dialogue).
So there it is. It doesn't seem like we have to move a whole lot to get
something that everyone is happy with. temas, haven't seen you online,
so I didn't get chance to chat with you too - what do you think?
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://jabber.org/pipermail/council/attachments/20030704/93afb4a2/attachment.pgp
More information about the Council