Several existing tools provide file-sharing capabilities:
WeTransfer
What it does?
To move a file from point A to point B, organizations that use 'WeTransfer' wait to upload their files to weTransfer(third party). This is then transferred to the clients by weTransfer through email. The receivers get an email to download the file from weTransfer's server
Problems:
- Files are stored in WeTransfer servers which is a huge privacy concern for organizations.
- Restricted file size for free and pro users.
- Does not support instant file transfer, needs to be uploaded to the cloud before anyone can receive the files
Persistence is not required in most use cases because most of the clients download the resources almost instantly or within that specific working day. Thus P2P makes more sense in this scenario as there is no need to upload. It's an instant share and the file is never sent to any third-party server. Thus making it efficient and inexpensive.
Opensource solutions are really amazing; people have taken the time to build innovative projects. The problems with the existing solutions are already listed in the GitHub issues of each project. For instance, snapdrop doesn't work for remote peers and works only on LAN. If the user is planning to upload a file in a conference and send it to 50 - 60 users, the user has to individually click on every peer and send it which is not convenient. Moreover, files cannot preexist before the peers join and users can't send files to multiple devices at once.
Most importantly snapdrop and sharedrop use (1-N) streaming protocol as illustrated below:
The master who initiates the transfer performs the transfer to all clients. This becomes highly inefficient when the peer size and file size grow because one peer gets overloaded with requests and bandwidth gets significantly narrow. To counter this scenario, blaze used webTorrent's API which makes sure everyone who receives the file helps each other to download the file like a torrent (N-N).
Unfortunately in webtorrent, files are loaded in the memory which prevents the upload of files greater than 600Mb in a phone and a hard limit of 2GB for computers. This setback is attributed to the fact that the file has to exist in the ram. Choosing one topology over the other has its own merits and demerits. Choosing the streaming mode makes sure an unlimited file size and high performance when using mobile devices. Using webtorrent below 600Mb is advisable because the transfer speed is insane when multiple peers join the system which becomes performant and efficient but has a hard limit and torrent creation wait time. To put it in a single sentence, webTorrent is not mobile-friendly as it imposes a significant load on the CPU and depends on the main memory.
So seeing the existing problems we thought, what if we can combine both topologies, use the right topology at the right time, graciously switch progress between both topologies and use them efficiently?
What if we can provide complete synergy between CLI and the browser?
As developers ourselves, we spend most of our time using CLIs and having the ability to transfer files from your CLI(like Airshare) to any other platform on any device would help boost productivity and provide convenience.
Now we know what exists, let's see in the next part what teleport 👽 has!
Top comments (0)