[Standards] file transfer
dave at cridland.net
Tue Aug 28 11:38:42 UTC 2007
On Tue Aug 28 09:39:39 2007, Richard Dobson wrote:
>> I digress, but... you cannot surf and call on GPRS at the same
>> time, generally. This is why if someone calls a GSM phone while
>> you are loading a webpage, they will generally go straight to
> Just to correct you here but they wont goto voicemail (if you are
> connected to WAP using a dial up method maybe), but you can
> definitely be downloading via GPRS/3G/HSDPA and still make and
> receive calls, i've done it myself.
Yes, but (certainly on my phone) it cuts the GPRS while you do so.
However, it's certainly possible to have multiple data transfers
going on in a single GPRS session, but that, of course, is using this
really cool bytestream technology called "TCP". I here it's used
quite widely, these days. ;-)
> automatic file pre-compression
> It would be handy to be able to automatically compress files before
> they are transferred and then be able to specify this in the SI
> negotiation allowing the receiving client to then automatically
> decompress the file once it has received it, this could greatly
> help with the size of file transfers and would also only need to be
> done for file types that would benefit from it, i.e. you wouldn't
> bother with files that were already compressed or things like audio
> and video files that are likely to only get marginal gains.
If you're transferring over a compressed stream (say, a modern TLS
implementation), then it's worth noting that compression algorithms
usually contain some mechanism for identity encoding.
This is needed because files with high entropy (ones that are already
compressed) would otherwise lead to alarming expansion. This allows
for not only transparent compression, but also transparent
non-compression, and allows applications to stop trying to
second-guess whether data is compressible or not.
Interleaving different data streams will defeat this, but if a new
data stream (and thus compression state) is used for each transfer,
this will work out okay.
If you want to transfer multiple files, do so either in distinct
sessions (if you want to do so concurrently), or serially within the
same session, with an intervening flush.
As an unrelated aside, TLS in this instance would benefit from
mandatory support for anonymous cipher suites. ADH et al would be
perfect for this kind of thing.
> jingle bytestream
> When we come to implement file transfer using jingle I would
> suggest that rather than creating a brand new backwards
> incompatible file transfer protocol that we simply implement a new
> jingle bytestream transport just like XEP-0047 and XEP-0065 which
> would allow complete compatibility with the SI negotiation but
> still gets all the benefits a file transfer over jingle UDP would
> bring, i.e. better likelihood of connection.
I'd be interested to here what Rob McQueen and other knowledgeable
folk would think about transferring files over ICE. I vaguely recall
there are existing mechanisms for layering SCTP over UDP, which
presumably might fit here and save a lot of work. (Not that SCTP is
quite what you want for file transfers, but it'll do).
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards