We have gone through all the flaws in the existing solutions and innovated the following features to help address them. This article provides a deep breakdown of all the features.
🎯Dynamically switches between topologies
Teleport can dynamically switch its topology 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.
| File streamed directly from sender | File shared using Web torrent API |
|---|---|
| All the receivers request files from only the sender and data is streamed via Webrtc. | It allows a torrent like a download in the browser where every peer helps each other to download files |
| Pros | Pros |
| Zero wait time. Since there is no pre-processing, file transfer begins the moment the connection establishes. | Scale as receiver list increases. For every new peer added it can receive files from n-1 other receivers. |
| 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. | Download rate increases with rising in peers. |
| Cons | 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. | 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 |
| The download rate reduces since only the sender shares the files with receivers. | 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. |
The hybrid approach towards this is what makes Teleport scalable and gets the best of both worlds. Initially, when file-sharing is initiated, the files are shared from sender to receivers through streaming mode(zero wait time) while torrent-creation is parallelly operated in a worker thread. If the peer count increases let's say more than 2 users and the worker thread has completed the torrent-creation, Teleport shifts to the torrent network where peers help each other. Existing peers who have downloaded files partially using streaming mode download what's left using the torrent protocol( this feature of memoizing chunk stores is something we added to web torrent's internals). Also, these peers seed their data, thereby helping newly joined peers download from existing peers and new peers to come. Thus we solve the initial waiting time faced in the torrent network by streaming the file from the master node and the receivers gracefully switch to web torrent at the right time through a hot memoization swap. We have our own forked modified version of webTorrent to achieve this.
How is this performant?
Assume 3 users are trying to download a 400MB file through their mobile devices, in a typical webTorrent scenario it takes 1.30 to 2mins waiting time and maybe another 1.30min to download from each other. With teleport, users receive 40% percent of the file in streaming mode instantly before the torrent creation time ends (1.30min). So now we download only the rest of the pieces in the webTorrent by swapping the new Store initialization with our existing partially downloaded store. Because of this web torrent doesn't start with 0% from scratch rather verifies the existing store with the hashes and moves on to download only the rest of the pieces which gets downloaded in 40 seconds. We save 50 seconds of transfer through this.
🎯Smart Environment Sensing
- The torrent switch happens only if the room has more than 2 peers, otherwise, it works in streaming mode peacefully perfect for the phone to pc scenario mentioned above
- If the file size is greater than 2GB, and a portal is created in the browser. We never initiate or use the torrent network rather just use the streaming mode. Take advantage of the hybrid topology for files greater than 2GB, by using teleport's CLI as we don't have any limitations of the browser there.
- If a specific portal has switched to torrent mode, and let's assume the file size is greater than 700MB and a new phone joins, teleport knows that the phone won't be able to participate in seeding the file cause of main memory limitations. The phone now becomes a leecher and downloads the file directly to disk.
leecher - a peer who downloads from everyone but will not contribute back by uploading.
🎯Secure Private Portal Transfer with Authorization
In public mode, the portal is exposed to all peers in the local network. Anyone can join the portal. Whereas in the private mode, we provide the user with a personalized profile of settings and some extra features.
- Firstly, the room name is updated to prevent earlier users from entering the portal.
- Secondly, peers entering the portal get authorized via Google and since we enable the receiver prompt by default only desired people can enter the room.
- Finally, these portals are not discoverable in the local network, meaning it provides anonymity to the sender.
Top comments (0)