Cluster Grid

Open Sync

Application Description

         TheOpen Sync is an open-source application aimed to allow the user to transfer files via wireless from an Android handheld device to a computer that runs a specific listening program.

The structure of the project

       The project was designed based on a client-server system . Consequently, it has two parts:

• The Android application, which acts a client. It allows the user to browse to the phone's filesystem, select multiple files and send them towards the PC.
• The PC application, which acts as a servers. Written it Java for compatibility issues, it listens for incoming connections and receives the files sent by a client, saving them to a designated location.

Development history      

        This application, developed as a summer-school project, was originally intended to be an open-source Android media server application. However, after the initial research into existing media-servers out there, we encountered a number of problems:

• Media servers use UPnP (Universal Plug and Play) as a means of communication, a series of communication protocols which, unfortunately for us don't even have RFCs.
• In order to avoid problems such as routers blocking certain ports, existing media-server applications send messages on a dedicated multicast address (239.255.255.255) and exchange configuration messages using HTTPU (HTTP messages send through UDP instead of TCP) . This wouldn't be such a big problem, considering that Java, and therefore Android applications can use the URL class and the ones that extend it in order to negociate HTTP requests and responses. However, after the initial phase is over, they stream files using and ad-hoc wireless connection. This is a serious issue, due to the fact that Android phones cannot participate in such wireless networks, and communicating via a router is tricky at best.
• The UPnP group , an organization that was formed in order to try and elaborate a series of standards for UPnP devices offers free SDKs for download, which can be used for newly-developed application. After deciding to try and use one of the SDKs provided,  we saw that, in order for two UPnP devices to communicate, they both have to announce their configurations and their "intentions"(what operations will each of them request from the other one). This is done by exchanging a special xml file (usually called "description.xml"). The onlly problem is that the configurations of the devices and the description of the required actions are specially issued by the UPnP group, and obtaining one could not be done in the given circumstances.

       After discussing the afore-mentioned issues, we decided to change the application and transform it into a file sycnhronizer. The reason for this choice was the fact that the open-source applications which served this purpose only had a command line interface on the PC side. So we decided to go one step further and develop a graphical user interface for the computer part of the application, thus making the entire system  more user-friendly.

Features available for the first version         

     Android application

        The initial screen waits for the user to input the IP Address of the listening PC server application, a password which will be validated by the server, and the path.

         The only field from the above ones which can be left blank is the path field ( in which case the browsing system will show the entire filesystem of the phone). We are aware that requesting the IP address might be a problem when the application is used by the general public, we found no other available sollutions in the given time frame for establishing a connection with the computer. 

         After the user presses the "List files" button, the window changes and the file browsing window appears. This allows the user to select one or more files, mark them, view the marked files and send them towards the server.

     PC application

         The PC server application was developed using the Java Swing libraries. It consists of a main window which allows the user to interact with the system. The features made available in the current version are:

• An Options window. The user can change the IP Adress the server uses to listen to incoming connections (this was added because most modern PCs have more than one valid network interface which can be used to access the Internet), change the download folder (the folder were the received files are stored) and add a new password (the server comes with a default password at the beginning of each session) .
• A Log window , which informs the user of changes to the state of the server (new connections, errors in the system due to network communications problems, or unauthorized applications trying to send data).
• A pop-up menu, which only appears as long as a file transfer is in progress.
• A File menu with an Open menu ite,m which allows the user to navigate through the file system of the PC and open files,  and an Exit item which closes the application entirely.
• A Window menu which allows the user to show/hide the Log and/or Options windows.

         The password system uses the MD5 algorithm both for the client and server applications. When the user inputs the password in the phone application a message digest of the password given is obtained and it will be sent before attempting to send the actual files. The server keeps a collection of allowed passwords ( which are also message digests obtained using the same algorithm) and when a new connection is established verifies the message digest sent by the client. If a bad password was provided then the server doesn't accept data from the client.

         The server system was designed using the Observer Pattern. The idea was to isolate the actual server, which handles incoming connections and the transfer of data from the GUI part of the application. However, changes in one of the components needed to be passed to the other one. This feature was obtained by the use of this general design pattern, therefore allowing the GUI to show the Log window  and the server to take the required actions when the IP, download folder changed or a new password was added.

Problems encountered

• Java JDK does not allow an application to listen on any port unless the connection is made on the localhost. To enable the client and the server to communicate on a wireless network we had to modify the line in the java.policy file found in the jdk foldera and comment the line which stated the above-mentioned rule.
• Any call to the accept() procedure associated to a socket is blocking. Therefore, we had to make the server class threat the this call on a separate thread, so that the GUI side will not be affected while the server waits for incoming connections.

Features that should be available in future versions

• Instead of simply sending a message digest of the password as the means for authentication, a better sollution would be using SSL.
• To avoid forcing the user to manually input the IP address of the server, a web-server could be used. The PC application would connect to the web-server at startup and send its working IP address. Then, the phone application would take the IP by inquiring the web-server.

Last Updated on Thursday, 30 June 2011 17:12