[JDEV] File transfers
Nicholas Perez
nick at jabberstudio.org
Wed Jun 5 11:52:47 CDT 2002
And of course you can always develop some sort of WebDAV or http hosting
to store files for file transfers. I know Jabber Inc. has this setup
with their client, Jabber Instant Messenger.
Mike Oliver wrote:
> Why have just one protocol?
>
> SMTP does pretty well at file transfers that are asynch. The Jabber
> protocol can include a header for the attachments and the user at the
> other end can decide if they want to download the file. The a request
> can then be sent to the originating peer and an SMTP transfer begun and
> the remote client can notify the user when the transaction is complete
> by asking where to put the file. There are SMTP libraries in almost
> every language you can name, so this doesn't appear to be a big problem.
>
> FTP is another and offers the ability to transfer files without the
> base64 encoding.
>
> Ollie
>
> At 11:45 AM 6/5/2002 -0400, you wrote:
>
>> In-band transport of large payloads is something we and others have been
>> looking at pretty intensely. Obviously it would be a nice thing to have,
>> but it is also very, very difficult to do properly. If you just stick
>> base64 in an X element, you have huge problems because if that takes 10
>> minutes to transmit, you can't send anything else for those 10
>> minutes. You
>> could chunk them, but that hardly makes things simpler for the client
>> software. This also makes it massively more difficult to distinguish
>> legitimate traffic from a denial of service attack. Furthermore, it means
>> the server has to do a whole lot more XML processing (which may
>> already be
>> a bottleneck), because all XML content has to be at least checked for
>> well-formedness. To speak nothing of the bandwidth implications.
>>
>> Ultimately, I don't believe there is a satisfactory way to transport
>> large
>> payloads in-band while keeping things simple for the client. The solution
>> to this problem will involve a more complex system on the client
>> endpoints
>> - though not necessarily in typical client software.
>>
>> -Mike
>>
>>
>>
>> |---------+---------------------------->
>> | | Andy Beetz |
>> | | <andy.beetz at clear|
>> | | swift.com> |
>> | | Sent by: |
>> | | jdev-admin at jabber|
>> | | .org |
>> | | |
>> | | |
>> | | 06/05/2002 10:29 |
>> | | AM |
>> | | Please respond to|
>> | | jdev |
>> | | |
>> |---------+---------------------------->
>>
>> >------------------------------------------------------------------------------------------------------------------------------|
>>
>> | |
>> | To: "'jdev at jabber.org'" <jdev at jabber.org> |
>> | cc: |
>> | Subject: [JDEV] File transfers |
>> | |
>> | |
>>
>> >------------------------------------------------------------------------------------------------------------------------------|
>>
>>
>>
>>
>> I've set up jabberd and got a couple of clients connecting to it
>> (winjab).
>> I
>> tried a file transfer which worked no problem. What I saw looking at the
>> Winjab source is that the receiver downloads the file from the sender on
>> it's own socket based connection.
>>
>> I'm just thinking that there should be a better way to do this and inside
>> the message. I'm not saying my idea is the best or anything, but I do
>> think
>> that it would present the client authors with less headaches. Anyway, my
>> idea is that a message element can have a child, let's say attachment or
>> even an x, which will contain the contents of the file. XML can handle
>> this
>> if the file is base64 encoded, as it ends up as plain text.
>>
>> Just some thoughts
>> Andy Beetz
>>
>>
>> ---------------------------------------------------------------------------------------------------------------
>>
>>
>> Clearswift monitors, controls and protects all its messaging traffic in
>> compliance with its corporate email policy using Clearswift products.
>> Find out more about Clearswift, its solutions and services at
>> www.clearswift.com.
>> ***********************************************************************************
>>
>>
>> This communication is confidential and may contain privileged
>> information intended solely for the named addressee(s). It may not
>> be used or disclosed except for the purpose for which it has been
>> sent. If you are not the intended recipient, you must not copy,
>> distribute or take any action in reliance on it. Unless expressly stated,
>> opinions in this message are those of the individual sender and not of
>> Clearswift. If you have received this communication in error, please
>> notify Clearswift by emailing support at clearswift.com quoting the
>> sender and delete the message and any attached documents. Clearswift
>> accepts no liability or responsibility for any onward transmission or use
>> of
>> emails and attachments having left the Clearswift domain.
>>
>> This footnote confirms that this email message has been swept by
>> MIMEsweeper for Content Security threats, including computer viruses.
>>
>> _______________________________________________
>> jdev mailing list
>> jdev at jabber.org
>> http://mailman.jabber.org/listinfo/jdev
>>
>>
>>
>>
>>
>> _______________________________________________
>> jdev mailing list
>> jdev at jabber.org
>> http://mailman.jabber.org/listinfo/jdev
>
>
> Michael Oliver
> Chief Technology Officer
> AppsAsPeers.com
> 7391 S. Bullrider Ave.
> Tucson, AZ 85747
> 520.574.1150
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
--
Nick
JabminRPC Developer
JabberSMTP Developer
ChatBot's B1tch
More information about the JDev
mailing list