[JDEV] File Transfer Proposals

[tom_waters at mac.com]

I have a file sharing client (in fact, that's all it does, no instant 
messages) built on a standard jabber server.

I do not use OOB because it doesn't handle HTTP PUT.  That's the only 
thing wrong with it from my perspective.  I am able to share files 
across machines when one of them is NAT'ed no problem using a simple 
http server I have built into each client. I haven't looked at PASS yes, 
but will likely use it as a way for two NAT'ed clients to communicate.  
I am planning on putting the PASS functionality into the clients, not 
the server however, so all p2p transfers happen on "someone else's" 
bandwidth.  The cool thing about using HTTP as the transport was I was 
able to integrate libCurl for the client side with almost no work.

Instead of jabber:iq:oob, I just created another protocol 
myapp:iq:myprotocol that has a direction=(put|get) attribute.  Clearly, 
I could have just told the other side to "get", but then i'd need a 
protocol extension to pass *that* message...


On Saturday, February 16, 2002, at 02:39 PM, Julian Missig wrote:

> PASS wouldn't be permanently storing mp3 and divx files and whatever
> else people send, it's just a proxy.
>
> I want to get OOB and PASS working with decent JEPs before we even begin
> arguing webdav & friends, because that has a lot of the filesharing and
> caching issues...
>
> As for using your own protocol, I'm not a fan of that at all. There is
> really no reason to recreate HTTP/FTP and other such file-sending
> protocols. The entire point of sending files out-of-bound is that there
> are existing protocols which already do it and do it better, because
> they have experience.
>
> In the end, using HTTP/FTP instead of writing our own protocol probably
> involves *less* work because there is craploads of code out there to
> copy, and HTTP/FTP don't have any of the bugs we may be creating when we
> create our own protocol.
>
> So, again I ask for comments which tell me *what is wrong with HTTP/FTP
> OOB and PASS*, not comments which tell me how you want to do it.
>
> Julian
>
> On Fri, 2002-02-15 at 22:02, aliban at gmx.net wrote:
>> hello again,
>> it might sound annoying but as i already mentioned i´m currently
>> working on a filesharing component, already done parts of it, will be
>> done next week(maybe).
>>
>> My idea behind filetransfer was not to send the file over jabber
>> server because this would flood the server soon with mp3 and divx
>> movies (esspecially filesharing). Whatever we have a xml
>> connection and that would be ideal to control the filetransfer, you
>> can send "abort", "resume" commands via jabber xml and do the
>> byte transfer with another very primitive socket that simple creates
>> a connection and pushs the data through it. In my point of view this
>> has two advantages. writing tcp sockets does not need much time
>> (in comparition with writing a http/ftp server). a simple tcp socket is
>> easier to control then many spawned http servers. consider, that
>> each http thread/http account would have to need it´s own
>> restrictions.
>> of course a http has the advantage that you can browse the
>> directories and find other interesting files but what if user does not
>> want to allow this? (i.e. he wants to offer this person only one 
>> file) I
>> wrote a iq for my jabberfs to enable filebrowsing as well as updating
>> the jabberfs databases...
>> http://skabber.rudbek.com/jabberfs/jabberfs-iq-files.txt
>> there you have two ways to find out what kind of files are offered at
>> this client. a) you ask for a full file list of all subdirs (it is 
>> optimised,
>> it wont send everything again each time but only the changes)
>>  b) you browse the file step by step by geting only the files of the
>> *current* directory. for the protocol for jabberfs is only onw iq not
>> finished yet, the jabberfs:iq:options to set the connection speed as
>> well as some other options like <firewalled/>
>>
>> btw, my jabberfs:iq:filetransfer is not so complicate. in general it´s
>> nearly the same as jabber:iq:oob. maybe we can accept it as an
>> alternative way to passing url/ it passes the ip + port
>> as well as some additional file information  (because i consider the
>> jabber xml as a good control way for the transfer)
>>
>> cya, Edrin
>
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>