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.

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.