[Standards] Seeking in file transfers
dmeyer at tzi.de
Wed Dec 10 20:38:33 UTC 2008
as written on the devel list, I'm thinking about adding seek support to
file transfers. I'm working on media networks in my PhD thesis and a
seekable stream is exactly what I need. First a small scenario why I
think it is useful:
I have a media server with a video file. This could either be a storage
server for my media files or a record server with the latest recordings
I made. Now I want to watch that video. The current approach is to use
the file transfer and start watching while the bytes are coming in. This
is similar to watching a video file over HTTP. But there are two
1. If it is a recording, I may want to skip the first minutes (recording
started to early) or skip the commercials. I don't not like to wait
until the file transfer has catched up.
2. Some video container have an (optional) index at the end of the
file. To play such a file the player should read the first bytes and
the last bytes before starting playback.
We also don't want to set up a new stream using SOCKS5 or a future
ICE-TCP every time the user seeks (IBB is a stupid idea here, so we
ignore it). So we have one stream for the data and should use XMPP
stanzas for controlling it.
I see two ways of doing it right now, maybe someone has a better idea
1. Add the number of bytes you want to receive on the stream.
| Player: send me bytes 0-1023
| File-Server sends the first kb over the data stream
| Player: send me bytes 1024-2047
| File-Server sends the second kb over the data stream
Well, 1kb may not be a good choice, maybe request 1MB chunks. It is
up to the application and use case.
Pros: good control over the stream
Cons: requires many XMPP messages.
2. Assume that the initiator wants to read the stream like a normal file
transfer and add some marks to the stream similar to HTTP chunks:
| File-Server sends "0 1024\n" over the data stream
| File-Server sends first kb over the data stream
| File-Server sends "1024 1024\n" over the data stream
| File-Server sends second kb over the data stream
| Player sends seek to byte 528743 command, but it takes some time
| until that request makes it to the file server
| File-Server sends "2048 1024\n" over the data stream
| File-Server sends third kb over the data stream
| File-Server got the seek request
| File-Server sends "528743 1024\n" over the data stream
| File-Server sends 1 kb starting from byte 528743 over the data stream
HTTP chunks use ASCII for the metadata like stream position, we could
replace "1024 1024\n" with a binary struct containing position and
length of a chunk.
What do you think about that? Should it be part of the Jingle file
transfer XEP? If 2. is used, the initiator of the session requesting the
stream should be able to turn it off for normal file transfer without
the metadata (maybe by setting chunk size to 0).
Did you know that dolphins are so intelligent that within only a few
weeks of captivity, they can train Americans to stand at the very edge
of the pool and throw them fish.
More information about the Standards