Its all started when I wanted to migrate to another mobile company. The market is very competitive and the prices are all about the same. One of the company offered a cloud backup service. Further investigation shows that in order to compete with other backup services the connection to this backup cloud does not comes out from your data plan. Now they got my attention *ultimate mobile traffic anyone?*. I said to myself I will take this plan only to "play" with their cloud.
I started to "play" around the cloud and really soon realized how primitive their software is: A crappy mobile app that does not really do anything beside restore and backup, and a crappy PC software which looks like windows 95. I hope for some virtual drive capability like Google Drive but on reality not even close. I decided that my first move is to make virtual drive over the cloud API. The cloud api is really basic http web api, something like upload_file.aspx, download_file.aspx and list_files.aspx. I started to implement a filesystem over this web api. I used FUSE which is basically kernel code that let the user-mode write filesystems. In order to simplify things there is this FUSE python module called fusepy which let you write filesystems in python! here is an example for memory based filesystem:
As you can see, you can implement the open, write, read, etc in python and basically you got working filesystem.. pretty cool I say. Using python requests module and fusepy I implemented all the filesystem functions I needed over the web api. One of the problems I encountered is that the basic web api server does not support "Range" http header, meaning I cannot seek, and a filesystem without seek cant really do anything. Then I discovered they have a share feature, when you press share you get a link to share your file. This link is on another IIS server which supports the range header, so I am able to seek. In order to make this work in the filesystem I programmed every open request to share the file, and save the share token in some array at the memory and cache it back in the next open. Also all the content on the cloud is encrypted to prevent copyright abuse requests. The filesystem automatically decrypt the content, and the softwares accessing the filesystem does not aware of that, as they read files from the filesystem they get un-encrypted content.
For now, this filesystem is read only because I didn't think of a way to seek on http upload form.
Because the filesystem is read-only, on the VPS\dedicated\PC I got a python script which can get a local file as argument and upload it to the cloud. At this point I can tell my server to torrent a movie for example, upload it to the cloud and I can watch it on the bus over LTE - on vlc - which getting the file from my cloud encrypted filesystem - without draining my data plan.
Next thing is to get Tunnel Over File, I am thinking with some sort of virtual TAP\TUN device constantly sampling the cloud files for received packets in the incoming range. The outgoing range it will upload each packet to the cloud for the other side to sample, but I don't think I will do it.. too much work and too much abuse of the service.
Thats it for this post..
No comments:
Post a Comment