Need a client/server application for our end users, allowing them to upload, download and manage their files that are stored on our servers.
The java client will reside on user's desktops and workstations. It is necessary for the client to run without bugs on Windows XP and Vista. Ideally the client should run on MAC OS X and Linux desktops as well (however this is not an initial requirement).
The java server will interface with our backend databases and file storages, handling communication, data transfers and authentication with the java client.
Java application Requirements
The objective of the application is to act as a client-server file manager.
Client: Users will use the java client to manage (upload/download/edit/delete) files residing on our servers.
Server: communicates with the java client providing an interface to our current database and file systems.
We currently have a java applet that talks to a java server, however the applet does not work on all browsers
and the server does not run on all hardware/software. You can get an idea on how some of the upload features
work and are referenced below by visiting: [url removed, login to view]
- Users will be able to login, authenticating with the java server against data on our
database. Once authenticated they will have access to their storage area and ability to manage any content
they have in their storage area.
- Users will be able to view/navigate (sort, scroll) remote files with an interface similar to windows explorer with
the added ability to sort by TAGs/Keywords. Users can also search their remote contents.
- Users will be able to edit and delete files in their storage area. Local folders and files can be uploaded
to their remote storage area.
- Users will be able to download files from their remote storage area to their local machine.
1- Users' uploads should be able to be queued and spawn multiple upload streams when they begin the upload.
Example: if user has 4 files, first the client will display processing for md5checksum (see below), assuming all 4 files
do not have a match on our file systems, the client will send the 4 files at the same time (a couple seconds
of separation is acceptable to prevent a hard/large start).
2- MD5 CHECKSUM. The client will first MD5 checksum their files before uploading. The md5 checksum needs to be transaparent.
The client should communicate the checksum to the server to find any matches. If there is a match, the file
will not be uploaded, but will be added into their remote storage area with a link to the matching content
on our file systems. The checksum value will be stored as meta data on our database, but it may be best to also retain an embedded
database or flatfile with local client files that stores the checksum to prevent the md5 checksum process
every time (sometimes users need the ability to re-upload the exact same file, due to accidental deletion or
they believe they have lost it and can not locate it via search/tag).
3- Users should be able to drag and drop files or browse files from their local machine into the java client, that performs the upload
4- Users need to be able to drag and drop, paste URLs supporting HTTP(s)/FTP(s) including FTP with user/pass such as:
ftp(s)://user:pass@server:port/path The content will go directly to our file systems through the java server. MD5 Checksum is
understandably NOT and option for this feature as it is not possible to get the MD5 checksum from a remote server via URL. It would
be best to have an option for a MD5 checksum to be provided and checked. Example: user wants to provide a URL to download a Kernel
ISO into their remote storage area. They paste the URL: [url removed, login to view] and in another text box the MD5 checksum.
If the checksum is provided, the java client should first check against the database for matching content to prevent re-sending the file.
The user should be able to provide many URLs in a queue manually pasting or drag and drop.
5- User needs resuming of a local upload. Resuming from a remote URL would be a great feature if possible as it is with ftp/fxp clients.
6- Progress indicators need to be displayed to the users when the client is communicating with the server when sending/reciveing data.
This is a numbered list of items highlighting uploading features in the application:
I) Drag and drop files/folders onto / browse and select files/folders into the client
Ia) the items will be loaded into java client's upload queue. when the user clicks to begin the upload process
first the md5 checksum is performed as explained above in UPLOAD METHOD #2.
Ib) items may be removed from the queue
II) Upload Queue.
IIa) Queue Display.
IIa1) the following should be displayed: filename, filesize, and last modified datetime
IIa2) the application/queue should display a 'send' button so the user can initiate the
process after they populate the queue.
IIb) Queue Display options: sorting by the filename, size, etc. add another column
to display an icon representing the entry in the queue (eg: folder icon for a folder,
file for a file, image for image type, url icon for urls)
IIc) Progress indicator for each item uploaded displaying: bytes transfered, bytes remaning, time remaining, percentage complete,
approximate transfer speed.
- Users will be able to download single files and whole folders. There needs to be a download queue. The download process
should behave similar to popular download managers (such as [url removed, login to view] for Firefox extention/etc).
Where a single file can be split into chunks and downloaded at maximum speed. Our servers are setup to perform downloads
with HTTP_RANGE when included in a HTTP header, you need to tell us if this makes sense or if the downloads would best come
from the java server.
- A download queue should be used allowing users to manage which content to download first, or load up with many files to be
downloaded over time.
- Users should be able to pause downloads/resume broken downloads just as download managers work.
- Progress indicators need to be displayed to the users when the client is communicating with the server when sending/reciveing data.
I) Drag and drop files/folders onto / browse and select files/folders to download into the download queue
Ia) items may be removed from the queue
II) Download Queue Display.
IIa) the following should be displayed: filename, filesize, and last modified datetime
IIa1) the application/queue should display a 'download' button so the user can initiate the
process after they populate the queue.
IIb) Queue Display options: sorting by the filename, size, download speed, ETA, etc.
IIc) Progress indicator for each item downloading displaying: bytes transfered, bytes remaning, time remaining, percentage complete,
approximate transfer speed.
Server needs to run on i386 or x86_64 linux operating systems v2.6.x kernel. Server can listen on any port. We are running MySQL database.
With our current applet/server we have to run multiple java servers per hardware server for performance. This is acceptable if necessary.
We estimate 2,000 simultaneous users communicating with the java client to the java server. Many users will leave their client always
open. This could lead to 10,000 users logged in/running the client but not actively using all the features.
We estimate the number of concurrent users to grow to 10,000 with 50,000 or more logged in "idle".