A bit of background is in order.
I work for SSi Micro (www.ssimicro.com). We're a dynamic little company that's responsible for building (from the ground up) a satellite network that delivers broadband internet to some of the most remote communities on earth, scattered around Canada's Northern territories.
One of the problems our customers face is that of simply sharing files. A customer in Iqaluit wants to share some big presentations with a customer in Inuvik, for instance. The usual path for the file transfer is this (suppose the user is attaching the file to an email):
User's home in Iqaluit -- (NextNet NLOS microwave link) --> baste station in Iqaluit -- (Satellite modem, bounce off our geostationary satellite) --> our uplink in Ottawa.
Now the file is stored in our main email server in Ottawa. Now the recipient checks their email, and it's the same path, but in reverse: Ottawa -> Satellite -> Base station -> home.
This is really slow and inconvenient for our users, and depending on how saturated our satellite link is, a long upload can time out.
We've decided to solve this problem with what we hope is a simple-to-use webapp that manages file transfers in a far more optimized way. Here's how it works:
The user logs into QFile (http://www.qfile.ca) and uploads a file. Instead of having the upload go to the base and then immediately over the satellite, the upload first goes directly to the base station. (Each community has a local instance of a QFile server.) The benefit of this is that the user sees a much faster upload time (our microwave links are not terribly fast, but they're a lot faster and more stable than the satellite hop). Once the base station receives the file, it immediately begins to deliver it to our main QFile server in Ottawa. Once the Ottawa server receives the file, it uses a multicast transfer to transfer the file to every other community in our network. This way, when any other QFile user goes to get the file, it's already on their local base station and they don't have to deal with the slow hop over our satellite.
The webapp is our attempt at a really simple file manager/"publishing" interface. The file manager is required because, well, users have to be able to manage the files they've uploaded. The "publishing" interface is (again, we hope) a simple way for the user to share the file with other users: Public (make a link anybody can click on), Email (email the link to a user for a one-time download), Slideshow (drag a folder of images onto here, get a link to a slick slideshow of those images), Workspace (invite a bunch of people to a workspace via email, and then update files as you wish and they're notified and can see all the files), and Facebook (push individual images or folders of images to your Facebook account).
We've been working really hard at making this a simple interface to what is a difficult thing to explain to our users (answering the question, Why wouldn't I just use dropbox? with a network diagram showing satellite hops and "pushing to the edge" isn't really that friendly). We'd love to know what you think.
http://www.qfile.ca
I've set up an account you can use to give QFile a whirl:
One of the problems our customers face is that of simply sharing files. A customer in Iqaluit wants to share some big presentations with a customer in Inuvik, for instance. The usual path for the file transfer is this (suppose the user is attaching the file to an email):
User's home in Iqaluit -- (NextNet NLOS microwave link) --> baste station in Iqaluit -- (Satellite modem, bounce off our geostationary satellite) --> our uplink in Ottawa.
Now the file is stored in our main email server in Ottawa. Now the recipient checks their email, and it's the same path, but in reverse: Ottawa -> Satellite -> Base station -> home.
This is really slow and inconvenient for our users, and depending on how saturated our satellite link is, a long upload can time out.
We've decided to solve this problem with what we hope is a simple-to-use webapp that manages file transfers in a far more optimized way. Here's how it works:
The user logs into QFile (http://www.qfile.ca) and uploads a file. Instead of having the upload go to the base and then immediately over the satellite, the upload first goes directly to the base station. (Each community has a local instance of a QFile server.) The benefit of this is that the user sees a much faster upload time (our microwave links are not terribly fast, but they're a lot faster and more stable than the satellite hop). Once the base station receives the file, it immediately begins to deliver it to our main QFile server in Ottawa. Once the Ottawa server receives the file, it uses a multicast transfer to transfer the file to every other community in our network. This way, when any other QFile user goes to get the file, it's already on their local base station and they don't have to deal with the slow hop over our satellite.
The webapp is our attempt at a really simple file manager/"publishing" interface. The file manager is required because, well, users have to be able to manage the files they've uploaded. The "publishing" interface is (again, we hope) a simple way for the user to share the file with other users: Public (make a link anybody can click on), Email (email the link to a user for a one-time download), Slideshow (drag a folder of images onto here, get a link to a slick slideshow of those images), Workspace (invite a bunch of people to a workspace via email, and then update files as you wish and they're notified and can see all the files), and Facebook (push individual images or folders of images to your Facebook account).
We've been working really hard at making this a simple interface to what is a difficult thing to explain to our users (answering the question, Why wouldn't I just use dropbox? with a network diagram showing satellite hops and "pushing to the edge" isn't really that friendly). We'd love to know what you think.
http://www.qfile.ca
I've set up an account you can use to give QFile a whirl:
username: qfile_test
password: test/account