Now after having watched the demo, you might have a lot of questions especially if you already know open source projects like sharedrop, snapdrop, webdrop, blaze and so on. Here are a few of the questions which you might get:
- How is this tool different than the existing ones?
- If I'm already using tool 'X', why should I switch?
- Does this tool provide better performance?
This post will hopefully get you on board with teleport by showcasing all of its stellar features and essential innovations. These include topics like how we created a zero wait time torrent creation mechanism etc.
Unique additions
- Dynamically switches between topologies
- Secure Private portal transfer with authorization
- CLI to browser PWA interoperability
- Real time CLI
- Sharing clipboard data using the async Clipboard API. Create a portal and start sharing your clipboard in a single click!.
- PWA support
- Fully controlled and customizable
- Connect once and stay connected with your friend
- Pair with new users who are physically nearby using soundwaves ( more seamless QR ).
- Giving users what they want
Dynamically switches between topologies
Unlike regular file sharing clients which have a fixed topology either works on a streaming mode like sharedrop / snapdrop or uses webTorrent's API like blaze, Teleport can switch its nature dynamically which makes it first of its kind. Why is this switch necessary? How does it make it better? Before answering these let's know the pros and cons of existing individual topology.
<aside>
💡 File streamed directly from sender. i.e all the receivers request files from only the sender and data is streamed via Webrtc.
</aside>
Pros:
- Zero wait time. Since there is no pre-processing, file transfer begins the moment the connection establishes.
- No file limit, since file is streamed(broken into chunks, only that is loaded in main memory and sent).
- Perfect if users want to send medium / large files (files greater than 100MB) from their phones to PC. The receiver count is only 1, why use a torrent network and pay for the CPU processing + waiting time when all you want is to send a file to one or two peers.
Cons:
- Does not scale as the receiver list increases. At one point there is a throttle on the sender side as it has to cater to too many requests and fails. Won't work for a large no of users.
- The download rate reduces since only the sender shares the files to receivers.
<aside>
💡 File shared using Web torrent API. i.e it allows a torrent like a download in the browser where every peer helps each other to download files.
</aside>
Pros:
- Scale as receiver list increases. For every new peer added it can receive files from n-1 other receivers.
- Download rate increases with rise in peers.
Cons: ( Not mobile friendly )
- Considerable waiting time according to the CPU, mobile phones suffer a lot with webTorrent than a PC. Before a torrent can come into action, there is a pre-processing step known as torrent creation time. This varies based on file size and processing power. For an estimate, it takes more than around 2mins to create a torrent for a 500Mb file on OnePlus 7T which has a considerably good CPU for a mobile phone.
- It has a limit on file size. For the seeding process, the file should be loaded into main memory, since it is a web-app that runs in a browser. So for any file more than 700MB when tried to send a file in a phone browser, browser crashes occur due to out of memory reasons.
- Even low-end PC's which have a pretty bad CPU suffers a lot of waiting time, not to mention sending a file greater than 2GB in pc is not possible with web torrent as the entire file has to be loaded into your ram.