[JDEV] File transfers

[Michael Rothwell]

RE: [JDEV] File transfersThe jabber server could simply have a config option for "max transfer size," which ,when set to zero, disables all file transfers. Clients are notified of the file-transfer capabilities of the server by the server. You could even take it one step further and allow/disallow file-transfter use per account ID and/or groups. Other config options which would be useful are "cache time" and "max cache size" -- if cache time and/or size are zero, then if the server cannot stream the data directly to the recipient(s), it informs the client that the recipient isn't accepting transfers. You could even limit the number of transfers/person/day, etc.

Leave it up to the clients to B64 encode/decode the transfer. The server doesn't have to care, which will reduce processing load. The "max size" parameters will be for the encoded versions, which is what server operators care about, because it's what they pay for.

Server-supported transfers would be a nice config option, esp. for behind-the-firewall and small-number-of-users servers.

  ----- Original Message ----- 
  From: Gallo, Felix S. 
  To: 'jdev at jabber.org' 
  Sent: Thursday, June 06, 2002 3:54 PM
  Subject: RE: [JDEV] File transfers


  Mike writes: 
  > Firstly, there is no inherent problem with sending moderately 
  > large files through a software server. Sendmail does it all 
  > day, every day, on a massive scale, without relying on 
  > client-to-client connections. 

  However, most mail is accessed through POP, IMAP, or Exchange, 
  which are definitely client-to-client connections -- for the 
  simple reason that sendmail doesn't scale very well.  For 
  every byte send to a sendmail server, two bytes traverse the 
  network.  Most unfortunately, those two bytes always involve 
  just the one sendmail server and its attached network. 

  What positives do you get for having the sendmail server involved 
  in a large file transaction between two parties?  You get a 
  guarantee of delivery and no need for continued storage on the 
  sending party's side (since the file 'moves' to the sendmail server). 
  If you're sending the file to multiple users at once, you get less 
  traffic on your local network (the server takes the load). 
  You also get an opportunity to mediate the file somehow (e.g., 
  virus checking it as a service, converting it from aac into mp3, 
  storing it for later delivery to other users..) 

  What positives do you get for not having the sendmail server 
  involved?  The network on the sendmail server sees 0X load 
  rather than 2X load; the latency is lower; the sendmail server 
  has no storage requirement; and you have arguably fewer points 
  of failure. 

  Pragmatically, taking the load off the server is more valuable 
  in the normal case than replicating HTTP/FTP/SMTP/FXP yet again. 
  The fact that 'SMTP does it' is not a great rationale for forcing 
  all the jabber servers to pay 2X bandwidth costs for file transfers 
  between their users. 

  F. 



  **********************************************************************
  E-mail sent through the Internet is not secure. Western Asset therefore
  recommends that you do not send any confidential or sensitive information to
  us via electronic mail, including social security numbers, account numbers,
  or personal identification numbers. Delivery, and or timely delivery of
  Internet mail is not guaranteed. Western Asset therefore recommends that
  you do not send time sensitive or action-oriented messages to us via
  electronic mail.
  **********************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20020606/9ea7d8a8/attachment-0002.htm>