Feb 7, 2006
by Matt Tucker

Why do most instant messaging systems get file transfer so wrong? Typically, file transfers don't work reliably (especially when firewalls are involved) and the file transfer UI is non-intuitive with problems like pop-up dialogs and the tiresome hunt to find where a downloaded file disappeared to. For the 1.1 release of the Spark instant messaging client, we set out to end all the frustration.

We began our quest for better file transfer with two major goals:

1. File transfer has to "just work", every time. Users should never have to worry about how their network is setup or firewall configurations.


2. Put the "user" into file transfer usability. File transfer is integral to the IM experience, so why throw up pop-up dialogs for sending and receiving files? Drag and drop should work. Overall, the feature should be a pleasure to use.

A Better User Experience

We focused heavily on the file transfer user interface for the Spark 1.1 release. Some of the major areas of improvement over version 1.0 are:

• All file transfer requests and progress dialogs are embedded into the chat window. After a file is downloaded, you can double click to open it, or browse to the download folder.
• Dragging files into the chat window now automatically initiates a file transfer.
• If the file is an image, a thumbnail of that image will be displayed. Otherwise the proper file icon is displayed.
• Pasting an image into a chat now works (Windows users, try the [Print Screen] button on your keyboard and then [Ctrl-v] in a chat window).

The screen shots below demonstrate sending and receiving files.

     

Making File Transfer Just Work

All too often (with other IM clients), we've had to give up on a file transfer that fails to connect and resort to sending the file by email. The usual culprit is a firewall or other network setting problems.

The combination of Spark 1.1 and the Openfire IM server works around file transfer connection issues with a three part file transfer approach. Each approach offers a different balance of speed and reliability -- but the key point is that the transfer method is always negotiated automatically. If one fails, the next approach is tried until the file transfer can proceed.

Each file transfer method is detailed below:

Peer to Peer

Spark will always attempt to establish a peer to peer (p2p) file transfer first. Peer to peer connections are the fastest option and work great when both users are on the same network (such as when they're in the same office location). However, p2p transfers almost always fail when one user is behind a firewall or using NAT (network address translation). Peer to peer file transfers are shown in the top diagram on the right.

Proxy Server

If a peer to peer connection fails, Spark looks for a proxy server to complete the file transfer (the middle diagram on the right). A proxy server is efficient at transferring files, although not as fast as a peer to peer connection. The file transfer will work unless one of the users is behind a strict firewall. Proxy server support is available as an external component now, and will be built into the upcoming Openfire 2.5 release.

In-Band File Transfers

If one of the other two file transfer mechanisms fails, Spark will default to sending the file "in-band" through the IM server by breaking the file into chunks of data and sending them as encoded messages (bottom diagram on the right). This method will work regardless of either user's network configuration but is slower than the other two alternatives.

Feedback?