MobiDFS: A lightweight mobile distributed file system

Transcription

1 MobiDFS: A lightweight mobile distributed file system Jilong Liao, Chi Zhang University of Tennessee, Knoxville, USA jliao2@utk.edu; czhang24@utk.edu Abstract Though Mobile computing area is getting increasingly popular during these several years, the current development of distributed file system does not catch up with the dramatic growth of mobile platforms. This paper proposes a new mobile distributed file system: mobidfs in order to place some implications on solving this problem. The generic idea of mobidfs is to reduce computing in mobile device by transferring computing requirement to server. By using server-and-client mode, this goal can be reached. Mobile device, such as Android equipped smart phone, tablets, and pads, have multiple communication interfaces which contain Wi-Fi, 3G, Bluetooth and Near-Field- Communication. This file system will choose the optimal way to transfer files when requested in order to reduce energy consuming. The implementation of this system allows users connect to the whole distributed file system directories without considering the factor of mobile device hardware platform. In addition, User privileges, which separate different users in the file system, are taken into consideration. Then, user shell as user interface was applied to gather some demo snapshots. Finally, this paper invokes the discussion about the new direction of distributed file system as a social oriented file system. I. INTRODUCTION Equipped with good computing abilities, storage capacities, sensors (microphone, camera, GPS, gravitational sensor, ambient light sensor, etc.) and various wireless network interfaces, smart phone can communicate with each other or remote sever easily in the world s largest network Internet. Thus, it provides an convenient platform for mobile computing. The rising demand for mobile computing asked for an improved network distributed file system that supports mobile devices, including portability, energy efficiency, extensibility, consistency and security. Regarding the sharply increasing amount of smart phone users, it is intuitive to have an idea taking advantage of these pervasive computing resource. File system is the crux in our design. The basic idea in our proposal is that we abstract the mobile devices, such as smart phones or PDAs, as a directory that mount to the whole mobile distributed file system and the system is working in a - model. Through this way, most of the low level complicated computing, e.g. locate resources and optimal data transfer route discovery, is moved to the server so that the mobile device can utilize its computing resource to serve mobile applications as much as possible. II. RELATED WORK Previous literature design many framework to address this issue, such as [1] proposed a framework for cloud computing on mobile devices. They implemented Hyrax, a platform derived from Hadoop that supports cloud computing on Android Fig. 1. Topology of the Mobile Distributed File System smart phones. Hyrax allows client applications to utilize data and execute computing jobs on networks of smart phones and heterogeneous networks of phones and servers. But the problem is that Hadoop is designed for clusters, and it is heavy weighted, so energy became one of the main constrain in this project. Their testbed is a cluster consisted of ten HTC Dream smart phones and Wi-Fi (802.11g) is the network interface. M-DFS [2] is proposed based on network file system mobile distributed file system for ephemeral sharing in proximity networks through Bluetooth and b. This paper studies NFS in the mobile environment and overcomes several shortcomings of the protocol when used under difficult network conditions disconnections, packet losses and low signal reception zones, which are typical in proximity networks. Caching is used mainly to improve performance (e.g. in low bandwidth-links), not to guarantee disconnected operation. MFS [3] is a client cache manager for a distributed file system to improve its performance. It focused on adaptation techniques for management of data accessed and modified by mobile hosts, through the use of prioritized communication, and an efficient cache consistency protocol using file access information to improve performance. However, those solutions are not suitable for a real mobile distributed file system. We propose a lightweight but full featured mobile distributed file system to support mobile application, such as file sharing, with energy efficiency, mobility, consistency and security. A. System Overview III. DESIGN OVERVIEW Our mobile distributed file system is a multiple communication interface and device transparent file system, which is fully

2 2 discussed in [4]. Devices exist in the file system as a directory which contains its own subdirectories. Therefore, a user can browse a remote device like going deep into a folder. The basic idea is to map each device to a directory in the whole system so that any other users can browse the system directory like what they do with his local directory in the mobile device. All device directories mapped to the system are under the system remote root: /mobihome. This directory will appear in each device as the system mount directory and it is the entry point of the system. The generic idea of this system, for another thing, is to be light weight and energy efficient on mobile device. Therefore, client and server working mode were chosen. We expect that the energy limited mobile device only involves computing as the least while requesting the server to do it as much as possible. This mechanism can both save energy in the mobile device and speed up the response from clients or server. s refer to mobile devices including mobile phone, mobile tablet, mobile pads, laptops and desktops. is the central machine that controls the system, handles clients requests and chooses optimal transmission method. Mobile smart phone are clustered or distributed in wireless networks connecting to the server via three different network interface: Wi-Fi, 3G and Bluetooth. The server is a desktop or laptop that connect to Internet or it can be reachable directly by mobile devices based on the location and network availability of mobile smart phones. As illustrated in Figure 1, mobile devices can communicate with each other through Ad-hoc networks setup by themselves; or they can connect to Access Point via ; or they can contact base stations with 3G network; or they just use Bluetooth to build an low power link. In this complex network topology, mobile devices are abstracted to directories mounted in the distributed file system so that users can easily handle files on different mobile devices, which means users only concentrate on files in the directories similar on PCs, rather than stumble by network switch off. - model are chosen to cope with the lower layer operations. In Figure 2, the server maintains four tables: resource table, mobile device profile table, and resource request ranking table. receives updated information. e.g. location, local resource directory, and requests from devices and sends out command and link decisions to the clients so that they can setup file transmission route. In the server side, as what is illustrated in the Figure 2 above, user device information and user resource information are stored in the data base. Incoming control messages from any of the communication interfaces will be parsed by an interpreter which could be regarded as file system scheduler. Thereafter, this message will be handled by Analyzer that performs some optimization algorithms. Analyzer usually will choose the best interface and vendor to minimize the possible energy cost by using the information such as battery level, IP address, GPS signal that report from each device in the heartbeat message. Network Interfaces in this system contain Wi-Fi, 3G, Bluetooth and Wired-Internet. Mobile devices may obtain various network interfaces but the most energy efficient interface will be used at a time. Upon these interfaces, socket communications are built between the server and the client. Both server and clients are running three listen threads in three different sockets where server and clients receive message. The three sockets are TCP listen socket, UDP listen socket and File Transfer listen socket. Among them, TCP listen socket is the major control message exchange channel while UDP is a backup. However, some of the message exchange will be on the UDP channel, such as heartbeat, because it is not in the essential message group which should be ensured to arrive correctly. File socket will only be used in the situation of the needs of file sharing. The server will send out control message that restrict the behavior of mobile devices. In addition, mobile devices are also connected with each other via sockets which will be used for file sharing and file deploying. Data base in the server stores the user information and resource information which will be used by Analyzer and Interpreter to identify the optimal resource or respond resource information request. Two tables are created and maintained in the server database: user table and resource table. The user table in the server s database contains information of user name, user IP address, network interfaces, GPS signal and battery level. The resource table records each file that each user wants to store in the file system and its metadata. In addition to this information, the resource table will record file s popularity so that the server can cache the popular file and offer the corresponding file request service directly to client. The client side also maintains a lite database which records the directory and file modifications in the daily use. The client program will put a time stamp to each record of modification so that next round heartbeat message can compress the directory updates and submit the changes to server. Once the local directories are synchronized with server, this database will update the time stamp to the current time. If the file is deleted, the database will handle it in three steps: record, report and delete item in database. User interface will be provided on the mobile device. Users will use this UI to get access to the system and to start browsing resources. All of user s operations and requests will be handled in background so as to offer a fluently operating environment. B. Communication Interface and Device Transparent Considering users may use various devices such as mobile smart phone, mobile tablets, laptops and mobile pads, the system needs to satisfy the need of device transparent so that users will not be bothered for the switch back and forth between client software. To achieve the device transparency, file system server needs to get full communication interface information of user device. Typically, Wi-Fi, 3G and Bluetooth are the primary concerns. In the current design, however, Wi-Fi is the priority communication network in the system for the following reasons. First, Wi-Fi is free and is used most frequently on different

3 3 Join ACK0 Info Info ACK1 dirupdate Dir ACK2 devices. Fig. 3. Join system and synchronization Fig. 2. System architecture mobile devices in the campus wide region. Second, the signal and link quality is stable for Wi-Fi which will reduce resynchronizations that is caused by the client-to-server contact failures. Third, the IP address assigned from WiFi DHCP server is unique external IP so that both server and client can listen to each other directly. Even though Wi-Fi is relatively energy consuming, the file system itself is not the major energy customer. Other network required software, such as Gtalk, Skype and Google Voice, are the major power sinks in the mobile devices. It is the fact that 3G is a network that can cover around the country with both lower transmission rate and less energy cost. However, this network service is not free for many of the users; also, a latency may occur when users request for large files. Another drawback of 3G interface is that current carriers use NAT to assign IP address, this means will block the packets sent out from the server at the gateway. Mobile devices are assigned internal IP address that is only useful under the same gateway which is completely different the IP address assigned from WiFi network. In other words, clients are blind to server in this network condition so that client will regard itself offline even it is online in the server side. Therefore, 3G is only a backup plan for this system until NAT issue is address, then 3G could serve users without WiFi access. Bluetooth is a very good power efficient message transmission protocols which can be used for device-to-device communication. This communication mode will be used after clients are required by server s control message. Since the coverage of Bluetooth, either GPS location algorithm or mobile network location algorithm is required to decide if two clients are suitable for Bluetooth communication. Thus, Bluetooth will only be used in the case of mobile devices are closed to each other or energy is limited. Device transparency requires a system to take network interface into considerations so that users do not need to manually decide which interface should be used. Additionally, users may use different platforms but those platforms should not disturb users operation because of the various communication interfaces. This should be solved by system background process after system server knows the interface information of C. System Scheduling System scheduling is the essential topic in the system since it includes six major schedule events: join system scenario, query resource scenario, search directory scenario, read file or directory status scenario, server cache request scenario, server heartbeat request scenario. In this section, the schedule protocols for each scenario will be discussed one by one in detail. 1) Join system and synchronization: This event happens at first when users start the program. As what is shown in Figure 3, the client program will send out a join message to server. Once the message is received by the server side, server will request client s hardware information, such as device name, network interface, GPS and battery. s will follow the command from server to read device hardware information and battery level, then send out this message. The server will trigger directory update request message after receiving the hardware information packets and store this information in the database. Finally, server receives directory update by responding an acknowledgment to finish the start session. At this time, server and client are synchronized with each other and both of their database have been updated. 2) Query Resource: Query resource is one of the highest frequency talk sessions employed in the file system. The detail protocol is illustrated in Figure 4. Suppose client 1 starts querying some resource by using copy command. initiates the work by sending out query message to server. When server receives this message, it will post a new thread to handle this request in the background, process which usually contains resource finding, resource location optimization, vendor contact and confirmation of information exchange. Asynchronized mode is applied in order to avoid disturbing users. After users identification of the resource and the optimal method that are about to be transmitted, server will inform the requesting client the way to contact the resource vendor. The last step is that the request user will contact the resource vendor directly and retrieve the resource. It is possible that server has been cached the resource that client 1 want to copy. In this case, server will return message saying that it has the resource and request client 1 to contact with him in file socket. Then client 1 will have conversation with server even though client 2 is the resource owner.

4 4 #1 #2 Q Ongoing Try WiFi ACK5 Data Open WiFi ACK4 WiFi FTP Search ACK3 Fig. 4. Query Resource Fig. 5. Search Another possible situation is that server contact client 2 for a specific resource but client 2 fail to configure its network interface, it will return failure information to server. In this condition, server will try different interface by the sequence of WiFi, 3G and Bluetooth. If all of these interfaces are failed, server will inform client 1 for request failed because the resource owner cannot configure its file socket. In addition, for the same scenario happens above, client 2 may be quit the system before the server knows it, because heartbeat message have a detecting period of 30 minutes. Therefore, server cannot contact client 2 until time out. At last, server has to send a failure and try again information to client 1. Though it is the worst case, but once client 2 join system again, the server will immediately cache resources in the client 2 because server think client 2 s link is not stable and this bad effect will damage the file system s consistency. 3) Search Directory: Search command will invoke this message event, as described in Figure 5, and the server will search the resource in the database and return the full path retrieving the resource to the requestor. This message uses UDP socket to transmit for two purposes: 1) It is not usual and does not require continuous connection; 2) If transmission failed, retransmit cost less than maintaining a TCP connection for a period of time. Potential failures may happen in the congesting wireless network. UDP packets may be lost in both directions from client to server and from server to client. This can be made up by try multiple times in the client side. It is not worth maintaining long time TCP connection in a busy network to ensure the arrival of a simple resource search request packet. A user may tolerant this failure by trying it again later rather than wasting precious energy in the mobile devices. 4) Read File or Directory Status: These two scenarios usually appear in the command of ls and stat. s send out the file or directory request to server, then server receive the request message and respond the corresponding information. For the same two purposes mentioned above, we use UDP instead of TCP. Figure 6 shows the connection flow. In some worst case that the resource vendor delete the file Fig. 6. R File S File R Dir S Dir Read File or Directory Status just after one user request it. The current file system allows this happen because the file system assumes that the probability of this extremely case is very low. Even this happened, the user will not be bothered because the resource is invisible to anyone after 30 minutes or file transfer request case is generated. 5) Cache Request: This is invoked by server which periodically scans its database to see if any of the resource is getting more popular. If any of the resource is discovered, server will ask the client for a copy, which starts the message communication demonstrated in Figure 7. When the server and target client are synchronized, they will switch to file socket pipe to transmit the resource till they finish it. Once the server cache the resource, most of the request for this file will be responded by the server itself. Only those users located close to the vendor and server think Bluetooth is the best choice, this file request will direct to the original file owner. Network failure or logical failure still exists in this scenario but the file system server will handle it in a similar way to try multiple times first. If still fail, the server will mark this client to be fragile client and it will cache all of its resources when client s network quality changes to good.

5 5 C Open FTP HB Ready Dir FTP Data Fig. 8. Heartbeat Detect Fig. 7. Cache Request 6) Heartbeat Detect: Since clients may leave the file system involuntarily for various reasons, such as power off, lack of network access and network congestion. Those will make the client invisible in the file system without informing the server. In this case, server will check whether the client is alive by broadcasting heartbeat information to all clients and waiting for responses. The client that receives the heartbeat information will respond the directory modifications as piggy back. The working flow is shown in Figure 8. A heartbeat message results no response from a certain client does not mean this client has left the file system, because the heartbeat message is sent out via UDP socket. Network performance will destroy this scheme if network is really busy. In case of this condition, the system will use additional alive check method that checks a user whether alive at each message it receive from the user. If the user has been lost contact, the server program will update its database table to make the user back into the file system again. This scheme could add computation work to the server, but it does not affect the responding time to the client. As the file system goes larger, multiple server can be deployed to handle the confliction in the server. D. User Interface On the mobile device, users will be provided a user interface to cooperate with the distributed file system. Typically, a shell should be displayed to users. Once the users joins the file system, the following operation should be assigned: 1) Browsing the directory: : users are allowed to browse both local and system mount remote directories. Since each directory owned by a user will be set different levels of privileges and access lists for the other users, only permitted directories are visible to the user who browses the directory. 2) Copy and move directory: : users can copy directory in the network from other user device to its local directory if privileges are acceptable. However, either move or write operation is constraint to directory or file owner. This is similar to the current file system that requires administration authority to move, write, delete or modify. 3) Set directory attributes: : physical device s directory can be both in-system and out-system. This can be defined by the owner user whether a directory or file should be in the system and what privileges should be assigned. 4) Read directory properties: : each directory or file should provide relevant information to any visible user, such metadata like file size, read/write privilege and ownership. 5) Search files: : user may know the name of the file without knowing the full path. This feature can help user find out the exact full path both local and in the system. E. User Privileges Logically, the distributed file system can only examine the directories public or accessible in each device. However, the physical device does not contribute all of its directories to the distributed system. Therefore, users need to obtain the authority to set, change and modify the privileges of all directories in the mobile device. User resource database in the server side records the privileges for each item. Some of them are public so that those are open to all users while the others are set as only accessible to a group of users. Other directories that are not set by users will not present in the distributed file system. In this way, we separate them into three categories: in-system directories, out-system directories, and different users. A. Platform IV. IMPLEMENTATION At present, the client platform for the distributed file system has been implemented in Android equipped smart phone and laptop. Typically, the minimal requirements that we specified for client device are Google Android 2.3+ operating system and the laptop supporting Java. Smart phones equipped with Google Android are chosen following thesefour reasons: First, popular smart phone operating system is prevalent around the world and more people prefer this kind of smart operating system. Second, Google

6 6 Android operating system is based on Linux kernel plus Davik Java run time which is the most familiar with developers and easy to modify. Third, it provides the easiest method to cooperate with other Google services that will be used for future development, such as Google Navigation, Google Maps and Google Accounts. Fourth, Android integrates the lightweight and embedded oriented database SQLite, which brings great convenience to the local data storage in the distributed system. On the other hand, the server platform that we implemented is Python 2.7 with MySQL database. The reasons why we chose Python with MySQL are first because Python saves a lot programming intensive work. Second, Python has more dynamic load advantages than Java or other languages. This property makes the development fluent without disturbing users in service while upgrading the distributed system service. Third, Python with MySQL has better integration with web service in Apache which could simplify the future development like search engine support and user web management service. B. User Shell Currently, we provide the client shell to allow user contact with the distributed file system. The shell commands list is the following: 1) ls: list all the sub directories that is visible for the request user. Usage: ls 2) pwd: to show the current directory both local and in the distributed file system. Usage: pwd 3) cd: continue browse the child directory both local and remote other device if accessible. Usage: cd <dir> 4) stat: print the directory s meta data both local and remote device in the distributed file system. Usage: stat <src> 5) cp: copy one file from the source directory to destination directory. Both local and remote is the same. If the request target is another device in the same distributed system, the system will handle the file request background. Usage: cp <src> <dest> 6) search: search the full path for a specific directory both local and remote. Usage: search <src> 7) setpublic: set a directory as public and put it into the distributed system. Then this directory becomes in-system directory. Usage: setpublic <src> 8) setprivate: set a directory as private only visible to a group of people and put it into the distributed file system. Then this directory becomes in-system directory. Usage: setprivate <src> <access list [,...]> C. Limitations Though the system is now working correctly and serve for any users, there are two major limitations: 1) only Wi-Fi is working; 2) No GUI for users. In the previous sections we discussed the multiple communication interface advantages, but we only implemented the Wi-Fi interface because the Bluetooth protocol is so complex and we did not figure out a possible solution for this project, meanwhile, the 3G network has NAT to change the IP address and port number so that the server is not visible to clients in 3G network. Another pitfall is the user interface in the client device. We only provide a simple command driven shell to operate however, graphic user interface is badly needed for smart phone since typing command is extremely difficult by comparison to clicking on the screen. The file recovery scheme is not implemented in the current prototype. If the file owner s hardware is damaged and the server has not cached the file yet, there is no other way to recover the file. Although we can assume the possibility of a user s hardware failure is impossible, the file recovery scheme should also be taken into consideration. One of the quick solutions is replicate each file in the server side at the beginning. This simple and quick solution, however, may be affected by a lot of versions of each file. To address this point, the file system has to provide versioning control service to make sure each version of the file s replicas has been well kept. One more limitation is that we think everyone own only one mobile device, so each device is separated with each other in the current file system. Unfortunately, a user may have multiple mobile devices such as smart phone, laptop and tablet. The present solution treats them as three directories that exist in the file system, even though they belong to a same user. This could be solved by change the minimal user count to user level rather than device level, and personal data synchronization service is provided in the file system. These four limitations are now in the future development progress. Solutions have been proposed to overcome these limitations that will provide better service than the current prototype. A. Experience V. EVALUATIONS After the prototype has been built and released, we have several experiences in this prototype. The following paragraphs recount the experiment operations. At the beginning when the client software starts, the server receives the join message from this client and requests the information of the device. Then the client responds to the server all information it needs, such as user name, network interfaces, GPS, battery information. This response invokes the server to update its database for the device information. Later the server asks for the directory update information. Once server receives the directory update information, the initialization synchronization is finished. The device is alive in the distributed file system. Then, the user wants to browse the /mobihome directory, it goes into the directory and sends directory request to the server while server will reply its corresponding directory information. If the user is interested in a certain file, he can first request the status of the file by using the command stat. Then the server will return the status information to the user.

7 7 Again the user may want to copy the remote file to its local directory; in this situation, the user can just apply cp command to make it. The file copy will be done in the system background process. Every ten minutes, the server will go through its database and send out heartbeat message and the corresponding client will response to the heartbeat message by reporting its directory modification in the last 10 minutes which stores in the local database. Reversely, if another user wants to copy a file in this user s directory, the file will be transmitted quietly in the background. If the file or directory owner user changes the privileges of certain file or directory, this modification will be both buffered in the database which is waiting for heartbeat message synchronization and report to server immediately. Once the server receives this report, it will adjust its corresponding item in the database. At last, the user closes the client program; the server receives the leave message and put the device status to be dead. B. Demo The above experience section will be presented as a demo. The demo setup in the following way: 1) One Google Nexus S Android 2.3 equipped smart phone runs the client program and one laptop runs the laptop client program. 2) Projector will show the server monitor screen so that it can be used to verify the functionalities of the system. 3) Both smart phone and laptop start working simultaneously and independently. The following figure 9 are shown the screen snapshot of the ongoing distributed file system. VI. DISCUSSION AND FUTURE WORK A. Personal Storage Synchronization Basically this system does not consider the situation that a user hold multiple devices, each device require synchronization with each other. One of the popular software is Dropbox [5]. MobiDFS is different from the concept that server will cache the files and start synchronization among all of the user devices. This is possibly the easiest evolution of the current mobile distributed file system. B. Uniform File Sharing Platform Based on the topic above, platform like Dropbox only concentrates on the personal data synchronization rather than peer-to-peer data sharing. Our current design satisfies the idea that provides a uniform file sharing platform. C. File Version Control Version control is not supported by the current system but it is still a possible development directions for this project. If combining personal data storage synchronization, uniform file sharing platform and file version control, this distributed file system will be very useful. Many applications like group document editing, mobile synchronizing editing, version related applications, etc. D. Social File System Fig. 9. Screen Snapshot This is a novel idea that the file system can be socialized. All of the designs and methods discussed so far are directory oriented, but we are much more interested in the undirectory based design, like tags which associate with a person in the social network. Therefore, we put forward a new idea: Social File System. This design will change the infrastructure of the distributed file system, because data are stored, synchronized and shared in a social mode by using tag or other similar techniques without having a real directory to direct the browsing. People who follow you on the social network can change the relationship with you and your device in the distributed file system. E. Challenges File distributing and collecting algorithms should work well with dynamic change of the wireless network conditions. Algorithms, including responder selection and routing, should be highly adaptive in order to keep an acceptable performance. Multiple network interface may be exist simultaneously and different battery lives are among smart phones. An accurate indicator model which combine all these factors should be developed to provide correctly device condition information to algorithms in Challenge 1. Privacy and security is needed to ensure a relatively reliable mobile distributed file system. VII. CONCLUSION In this project, we design and implement a lightweight mobile distributed file system with device transparent service. The implementation provides an real distributed file system

8 8 prototype that is now in service. This design is a fundamental design that worth extending to further evolution that combine personal data storage synchronization, transparent device file sharing and social networks. REFERENCES [1] E. E. Marinelli, Hyrax: Cloud computing on mobile devices using mapreduce, CMU, Tech. Rep., [2] N. Michalakis and D. N. Kalofonos, Designing an nfs-based mobile distributed file system for ephemeral sharing in proximity networks, in Proceed of 4th Workshop on Applications and Services in Wireless Networks, [3] B. Atkin and K. P.Birman, Mfs: an adaptive distributed file systemformobile hosts, Departement of Computer Science, Corbnell University, Ithaca, Tech. Rep., [4] J. A. Strauss and M. F. Kaashoek. [5] Dropbox, Dropbox,