Speedify LIVE Office Hours: Q&A With Our Developers

Our 199th episode of Speedify LIVE we hold our weekly Office Hours with the Speedify Devs to answer all viewer questions and more!

We take a look at some very specific questions from viewers as well as the Mailbag, discuss what’s coming in Speedify 13.3 and geek out about streaming to TikTok!

Here are our 5 takeaways from our Office Hours!

1. When it comes to Speedify vs MPTCP, there’s a few differences: MPTCP is very latency based, vulnerable to loss and jitter; while MPTCP can use multiple TCP sockets, it can only use one on each connection – Speedify can use 8! MPTCP is also less cost-aware, with just two modes of either using one connection at a time or all of them – Speedify knows which connections are cheaper, and will use those first. 
2. Speedify doesn’t have any problems with double NATs, but it also depends on what you’re doing! For connections to go out, the client has to start everything; but if you’re running a server, trying to have incoming connections, then you would need a Dedicated Server that will allow Port-Forwarding so you can send specific ports to specific computers. 
3. While Speedify handles unstable LTEs pretty well already, our upcoming releases will make further improvements! Currently, Speedify takes into account the bandwidth, latency and loss of the connection, and does a great job at dealing with failing connections and new ones coming in; while Speedify 13.3 will add another dimension to it: tracking jitter to more carefully watch how latencies change. 
4. We are now streaming to TikTok! The Speedify TikTok channel has finally qualified for live streams, so we are testing it out, seeing how it works, and seeing results: a lot of people who watched us on TikTok have also followed the channel!
5. Our Mailbag Question was about speed issues with Speedify, but it turned out the solution was simple! The user in question was connected to a server that is very far from their location, which can naturally cause some degradation. The solution can be closer servers, or different Transport Modes; in this case switching to UDP did the trick!