Universal Data Share
We've all been there: needing to send a file to a friend or colleague, but which method to use? Could email, but the maximum attachment size is only 10 MB while the file is larger. Got to chop up the file into smaller bits. Or use an FTP or HTTP server to upload it to. Or use a filesharing website. Any method is complex and everything but straightforward. Universal Data Share changes this.
Just start UDS, put the files you want to share into its local list and send your IP (local if on LAN, global/external if on WAN) to your friend who can then immediately see those shared files and download them at his leisure. UDS simply makes use of what networks do best: share information.
See the original blog post in which I announced this project: Qt and custom network protocols, or the holy grail of the internet.
UDS makes use of the Internet Gateway Device (IGD) specification of the UPnP protocol which allows applications to set up forwarding rules on UPnP-enabled routers. This is how a peer-to-peer connection can be set up without having to make use of a server. The subsequent communication uses TCP with a binary protocol for message and file transfers.
The current version is implemented using C++/Qt. It should successfully compile and run on Windows, BSD, Linux, OS X and other OSes implementing BSD sockets and supported by MiniUPnPc (for IGD) and Qt.
UDS is currently in Beta status. All required features are implemented, but with bugs still remaining.
You can download Windows binaries of the current version here: Statically compiled binary for Windows. It should run on Windows XP and up.
The source can be found at https://github.com/MayaPosch/Universal_Data_Share. As noted above, the Qt and MiniUPnPc libraries are required to compile it.
The protocol is still under development, but the (probably current) protocol looks like this:
Universal Data Share Protocol Revision 0 Defines the protocol used with UDS-compatible applications. 2011/10/25, Maya Posch (c) Nyanko.ws --- Implementation details: - byte order is little-endian throughout the protocol. BASE HEADER size uint32 NYANKO uint8(6) UDS uint8(3) revision uint8 [command] Size is the total size of the message being sent, including the full header. Two text strings are followed by the revision number of the protocol. It's set to 0 during the Alpha development stage. LIST command Client: LIST uint8(4) Server: LIST uint8(4) file ID uint32 | file size uint64 | [repeated for each file] name length uint32 | filename uint8(length) | This command provides the client with a list of available server-side files. The file ID is the ID as known at the server side. The file size is the size of the file in bytes. The file name is of variable length, as specified by the preceding length. These four items are repeated for each file in the list. FILE command Client: FILE uint8(4) file ID uint32 Server: FILE uint8(4) filesize uint64 filename length uint32 filename uint8(length) segments uint32 SHA-1 hash uint8(20) filedata uint8(*) This command is used to download a file from the server by the client. File size, name, length should be self-explanatory. Segments is the number of segments the file's data is split into. Hash the SHA-1 hash. See the HASH command below for details on additional segment messages. HASH command Server: HASH uint8(4) segment count uint32 SHA-1 hash uint8(20) filedata uint8(*) This command marks messages containing additional segments of a file transfer. The sequence number is indicated as well as the hash of the attached file data. Hash algorithm used is SHA-1, resulting in a 160-bit hash. Segment index starts at zero.