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@clear|
| | swift.com> |
| | Sent by: |
| | jdev-admin@jabber|
| | .org |
| | |
| | |
| | 06/05/2002 10:29 |
| | AM |
| | Please respond to|
| | jdev |
| | |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
|
| 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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
