[JDEV] File transfers
Andy Beetz
andy.beetz at clearswift.com
Thu Jun 6 00:58:18 CDT 2002
What about the nntp idea for very large posts? Where the file is split into
several parts, each part being only small in size could be transmitted
in-band just one at a time. As long as they carry header information the
client at the other end should be able to decode and re-assemble. It should
be possible to request parts if they're missing.
-----Original Message-----
From: Michael F Lin [mailto:MFLIN at us.ibm.com]
Sent: 05 June 2002 19:23
To: jdev at jabber.org
Subject: Re: [JDEV] File transfers
When we generalize the Jabber network to thousands of servers, it becomes
something of a nightmare to transport stuff out of band. This is of course
why HTTP is not too good for this purpose - too many people are behind
firewalls. Any direct client-to-client connection with whatever protocol
will of course have the same problem. Relying on e-mail routing is one
option, but how do you negotiate what address to send an e-mail to? How do
you receive it? What if you need a file but don't have access to your
e-mail?
There are any number of solutions you can set up with WebDAV and so forth,
but what we would really, really like - particularly when it comes to Jabber
as a transport for web services - is a way to transport large payloads if
not directly in-band, then in a band that fully adopts JID routing. Jeremie
has proposed PASS, which is a step forwards but not totally satisfactory.
The only "good solutions" I've been able to think of basically involve
running a Jabber server that knows how to route s2s on every client machine.
Which is, not coincidentally, something I'm working towards.
-Mike
|---------+---------------------------->
| | Mike Oliver |
| | <ollie at appsaspeer|
| | s.com> |
| | Sent by: |
| | jdev-admin at jabber|
| | .org |
| | |
| | |
| | 06/05/2002 12:21 |
| | PM |
| | Please respond to|
| | jdev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------
---------------------------------------------------|
|
|
| To: jdev at jabber.org
|
| cc:
|
| Subject: Re: [JDEV] File transfers
|
|
|
|
|
>---------------------------------------------------------------------------
---------------------------------------------------|
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
_______________________________________________
jdev mailing list
jdev at jabber.org
http://mailman.jabber.org/listinfo/jdev
---------------------------------------------------------------------------------------------------------------
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.
More information about the JDev
mailing list