This is an idea I've been mulling over in my head for a few weeks. After working with the Dropbox API for a little while, I started thinking about some interesting things that could be done with a service that allows you to upload arbitrary files and make them available at a predictable file location (the Dropbox public folders that were available before October 2012 will upload files to
), meaning that as long as you knew what the file was called and had a userID, you could download multiple files with the same name. So the idea is, if two people knew each other's ID, and you had an agreed upon location to upload data, you could use Dropbox as a way of sending (insecure) messages to each other without knowing anything about the other host machine besides the Dropbox ID of the person running it.
The implementation is really quite simple. It's usually set up in the way of a "server" and a "client". The server writes a message file to the predetermined location (I'm using
where userID is the id of the person you are sending to. The ID is to allow multiple "connections") Dropbox will then automatically upload the file into a location that the client knows about. All this time, the client is trying to download that message repeatedly until it gets it. The message is prepended with a message number so the client can differentiate between the current message and a new message, necessary due to the asynchronous nature of the protocol, as there is no actual "connection" to speak of, it's all implied. The client then reads the message, takes the necessary action, and sends a response in the same manner, by writing to a file in their Dropbox folder. The server reads this message, takes action, and the cycle starts over again. This can go on for as long as necessary until the messages have done their duty.
Since these are just binary files, you can implement most any one-to-one messaging system with these. A PING server is really easy to implement,, one side uploads PING, the other side sees it and uploads PONG, and they just do this back and forth until you make it stop. There's an implementation of this in the git repository
under dmpserver.py and dmpclient.py for the server and client, respectively (client sends PING, server sends PONG). However, a PING server is really not very interesting. That's why I created...
DFTP - Dropbox File Transfer Protocol
The biggest problem with sending data over the internet is that it’s basically impossible without giving someone money or having a server of your own (or a static IP or the ability to forward the ports on your router). Dropbox helps with this because it lets you upload large files and then lets other people download them. The problem is that Dropbox only gives you 2GB of space for free, so you are limited to sending files that are 2GB in size. So what's the best way we can exploit Dropbox's amazing service that they provide to us without charge? Well, using DMP and DFTP, we can chunk up the file and send arbitrarily large files through Dropbox automatically, by only uploading pieces that will fit in our Dropbox folder at any given time.
The protocol is very simple, the server sends a message with the filename for the client to save as. The message number on this is always 0. The client creates a file with that name somewhere on the machine and responds, saying “Received!”, because it got the message. We can then start chunking up the file. The server takes the file, grabs the first chunk of n bytes (usually it should be in KB, but whatever) then writes that to a new file in the Dropbox Public folder and waits for it to upload. Then, it sends a new message, with the last message number +1 and a filename for the new file (relative to the public folder, i.e. a file called Public/foo/bar would use the name foo/bar). The client then downloads the file it gets from the message and appends it to the file it created. This gets repeated until the server sends “Done!”, signifying the the file transfer is done and both sides can "disconnect".
The obvious downside (if you've used DMP at all) is that the bandwidth will be horrendous. The file chunk first has to get uploaded to the Dropbox servers, which is hardly something that is given high priority, then you need to send the message, then finally the other person can get the message and download the file chunk. The ping time for a DMP message can be well over 3 seconds, so you had better make the chunk size sufficiently large for this to be worth it. For instance, in testing this, I sent a 12 killobyte file with a chunk size of 1024 bytes. With a ping time of 3 seconds and needing to send 14 messages (an init, 12 file messages, and a finish) sending the file took 42 seconds in latency alone. The internet hasn't been this slow in the entire time that I've been alive. However, chunk size in this case is not quite the same as packet size when sending over TCP/UDP. Since we are uploading to Dropbox, we can upload chunks up to the size remaining in your Dropbox folder. When I bought my Galaxy S3, I got an extra 50GB of Dropbox space, so I can send chunks up to ~48 GB, so if I want to send a particularly large file, I can really minimize the DMP latency by just using a ridiculously large chunk size. By default you get 2GB of space, so you can use around that size of chunk, again basically negating the DMP latency all togethe (compared to download time).
I've created an implementation of DFTP in the aforementioned git repository
under the names dftsender.py and dftpreceiver.py, for the sender and receiver, respectively. For max cross platformability these are just command line tools (they work on Windows and Linux from my testing, I don't have a Mac to test on that but it should be fine) and will run as long as you have python 2.6-7. A platform specific GUI wrapper could be made around these for ease of use, but as a proof of concept for a mostly intellectual exercise, the command line tool is sufficient.
Again, the git repo for this can be found on Gitorious
and a backup can be found on Github
. Permanent links will be in the Esoterics section
of this site.