This is Alex from Connectify. Sorry to hear you weren't happy. We put out a new release *yesterday*, with huge improvements on how both loss and jitter are handled. Since you have both, I think this could fix your issues. Assuming that you are who your slashdot profile says you are, I just emailed you another license. Please give us another try, we're here to support you. New software here: http://speedify.com/blog/speed...
Thank you for considering Speedify.
A MPTCP VPN would not work in the real world. When you tunnel TCP through it, you end out having to send ACKs for the ACKs. The end result is that the effects of even a tiny bit of packet loss is a performance meltdown: http://sites.inka.de/~W1011/de...
To build Speedify, we needed to implement a new multipath protocol over UDP. But that let us do clever stuff with NACKing and retransmitting lost packets before TCP ever noticed, and we were actually able to reduce the effect of loss: http://speedify.com/blog/speed...
Hey, thanks for the mention. This Alex from Connectify. We've launched a new VPN service called Speedify that combines multiple network connections. It's very smart about jitter and retransmitting lost packets. I think it's exactly what the OP is looking for: http://speedify.com/blog/speed...
Hey, sorry for the hard sell, but this is exactly what Speedify does. It's a VPN that uses multiple connections. It also detects, and retransmits lost packets long before TCP notices. Latest beta has been tested on Amtrak trains combining their Wi-Fi with Verizon 4G. Please check it out: http://speedify.com/blog/speed...
The servers can't handle getting the data from different IP addresses.. That's why you need a VPN-style server in the middle to put the packets back together in a sane way. This is what we do with Speedify: http://speedify.com/blog/speed...
Ha, that's exactly what I thought when I started implementing it. But it turns out it's way harder than it appears. Differences between internet connection in latency, loss,bandwidth, jitter, and buffering all conspire to make this a very difficult, multiyear project. That said, we've done it already and put servers all over the world, so you can just sign up and use it. Speedify: http://speedify.com/blog/speed...
This is what we do with Speedify: it's a VPN that uses all of your Internet connections at the same time. By the time we started dealing with issues like jitter and loss the level of effort exploded into years. That said you should check it out: http://speedify.com/
What you have described is Connectify's Speedify, it's a VPN that combines multiple internet connections together. As of the latest release it handles both jitter and loss, please check it out: http://speedify.com/blog/speed...
Thanks for asking, this was part of a campaign to sign up technically sophisticated beta testers for our new VPN product. I came to slashdot because of the concentration of such networking experts. The casual, ask me anything, tone was set specifically to disarm the frequent, negative posters who frequently post without contributing to the discussion in a meaningful way. At this moment, I have now signed up 249 people for the Switchboard beta (thank you everyone, we won't let you down). Thanks for your post.
Interesting, thank you. In general I think the trust/privacy issues are bigger here on Slashdot than they are in the rest of the Internet (I submit Facebook's success as evidence). I think the subscription part was a bigger deal to more people. That said you clearly have a valid point, and your stories about those other products are clearly nightmarish. I'm going to keep this in mind going forward. And I get that nothing I say here will make you trust me. So are there standards/trusted 3rd parties, whose seal of approval would make you believe in our security/trustworthiness?
Thank you for asking. Yes, so in the new form, we're pushing it largely as a personal VPN. It's very easy to setup, and automatically does the same sort of firewall traversal (STUN, TURN, different ports, etc.) that Google Talk or Skype does to get through a firewall. So you can get a VPN server setup without having to deal with port forwarding on your router, or anything like that.
We are smart about our channel bonding and protocols. As long as it's possible, we'll use UDP and get much better speeds than you would get with a TCP based solution.
It does have the multiple Internet connection stuff going as well. Yes, for that to improve your performance, you have to set up your server somewhere with a very fast Internet connection. There are a lot of situations where this comes up: places where DSL is still common, and where you have a very mobile workforce, a lot of times people have access to both Wi-Fi and 4G or DSL and 4G.
Thank you, good feedback. We're going after the personal VPN first, but I think that eventually we'll be able to return to the cloud server. There certainly were a fair number of people who really wanted it.
Linux will be a supported platform for Switchboard. We did a much better job of building cross platform C++ with an HTML user interface from the ground up. Dispatch's a code has a lot of Windows specific stuff throughout it, the port would have be a new development effort almost from scratch. So I can't really say if Dispatch will really ever happen on other platforms (it could but... not soon, anyways).
I felt like a lot people started off negative, but when I started actually answering, everyone seemed really well behaved. I was happy, I think that maybe more people from the stories should just jump into these conversations. In the end, I didn't have any bad "troll" experiences.
Ok, what the hell. My father is Evangelos Gizis. He's an academic, who among other things has done stints as the President of Manhattan Community College, President of Hunter College, and Provost of Queens College. He still wishes I had taken school seriously and gotten a PhD.
More and more, I'm coming to think of myself as a guy who takes complex networking technology and tries to make it simple. I'm doing this because I want to give people not only faster internet access, but also free them from the companies that would control what we can do on the Internet connections that we're paying for. Well that's my big vision, mostly I answer emails, and wish I had more time to actually code.
Ha, no really, there were a lot of good points. I thought that the confusion as to what the core technology REALLY did, and the resistance to yet another cloud service/subscription really explained a lot of what I was seeing and hearing on Kickstarter. On Kickstarter, you hear from people who are excited, but very little from the 99% who don't decide to back you, they just wander off if they're not interested. Here on Slashdot, people were a lot more vocal.
I do get how unbelievably negative Slashdot can be. Take the first Slashdot story that ever covered Connectify.... What did I get 200 comments on Connectify, probably all negative. But I got 20,000 downloads of the software in the 8 hours after the post went up. So it's not obvious from reading the discussion but there actually were 100x as many people who liked the idea, as hated it. (Oh and then we decided that this really could be company).
Sorry, you're right. Here's what changed: Originally this was going to be cloud based service. We'd have servers all over the world, which would aggregate your connections for you to give you faster Internet. But people wanted to run it themselves. And once that happened, we realized that we might as well make it clear that Switchboard is really a VPN. So once you're running your own server, you can start sharing resources off your network with yourself, wherever you are.
Ok, I got a little dramatic in the title of the post. Body is accurate though, I really did get a lot out of the discussion here. People thought it was just a load balancer, and everyone was very wary of yet another subscription. It was real feedback that helped explain a lot about what was going on with the campaign.
Absolutely, that was the main scenario we were thinking about as we designed this. It does a nice job of putting links together so you really can a skype video call from the hotel. Since then we've been amazed to find out how many other scenarios there are: people with 2 DSL lines to the houses, business disaster recovery scenarios, people needing to get video streams into or out of areas where they can only get 3G service... the list keeps growing. But yes, the business traveler was who was in our mind at the start.
If we get a packet but haven't yet delivered the previous one in the sequence, we hold onto it until we either get the missing packet, so we can deliver what we have in order, or until we've seen a packet come in on all interfaces, and can declare the missing packet as lost, and then deliver everything we have.
Oh, I see what you're thinking. No, we don't make a mess of anything.
Look at our typical scenario: two ISPs, let's say 7Mbps DSL and 10Mbps cable and latencies that differ by, let's say, 20ms, with careful reordering you can see single-socket performance of about.95*(10+7) with average packet latency somewhere between the two. Without some careful reordering, TCP is very good at slowing way, way down, and a lot of UDP media streamers just fall apart completely.
If you're us, and you get a packet but you haven't yet delivered the previous one in the sequence, the right thing to do is to hold onto it until you either get the missing packet, so you can deliver what you have in order, or until you've seen a packet come in on all interfaces, and you can declare the missing packet as lost, and then deliver everything you have.
As far as SACK and D-SACK, you don't really want to do that for the 30% of your packets that arrive out of order. From what I've seen in the real-world, those RFCs are not intended for coalescing streams where potentially a lot of the packets are out-of-order (as they would be in the DSL + cable example).
Slashdot Mirror
This is Alex from Connectify. Sorry to hear you weren't happy. We put out a new release *yesterday*, with huge improvements on how both loss and jitter are handled. Since you have both, I think this could fix your issues. Assuming that you are who your slashdot profile says you are, I just emailed you another license. Please give us another try, we're here to support you. New software here: http://speedify.com/blog/speed... Thank you for considering Speedify.
A MPTCP VPN would not work in the real world. When you tunnel TCP through it, you end out having to send ACKs for the ACKs. The end result is that the effects of even a tiny bit of packet loss is a performance meltdown: http://sites.inka.de/~W1011/de... To build Speedify, we needed to implement a new multipath protocol over UDP. But that let us do clever stuff with NACKing and retransmitting lost packets before TCP ever noticed, and we were actually able to reduce the effect of loss: http://speedify.com/blog/speed...
Hey, thanks for the mention. This Alex from Connectify. We've launched a new VPN service called Speedify that combines multiple network connections. It's very smart about jitter and retransmitting lost packets. I think it's exactly what the OP is looking for: http://speedify.com/blog/speed...
Hey, sorry for the hard sell, but this is exactly what Speedify does. It's a VPN that uses multiple connections. It also detects, and retransmits lost packets long before TCP notices. Latest beta has been tested on Amtrak trains combining their Wi-Fi with Verizon 4G. Please check it out: http://speedify.com/blog/speed...
The servers can't handle getting the data from different IP addresses.. That's why you need a VPN-style server in the middle to put the packets back together in a sane way. This is what we do with Speedify: http://speedify.com/blog/speed...
Ha, that's exactly what I thought when I started implementing it. But it turns out it's way harder than it appears. Differences between internet connection in latency, loss,bandwidth, jitter, and buffering all conspire to make this a very difficult, multiyear project. That said, we've done it already and put servers all over the world, so you can just sign up and use it. Speedify: http://speedify.com/blog/speed...
This is what we do with Speedify: it's a VPN that uses all of your Internet connections at the same time. By the time we started dealing with issues like jitter and loss the level of effort exploded into years. That said you should check it out: http://speedify.com/
What you have described is Connectify's Speedify, it's a VPN that combines multiple internet connections together. As of the latest release it handles both jitter and loss, please check it out: http://speedify.com/blog/speed...
In fact, this does exist off the shelf already, it's called Speedify, and it's a VPN that uses all of your connections together: http://speedify.com/
Thanks for asking, this was part of a campaign to sign up technically sophisticated beta testers for our new VPN product. I came to slashdot because of the concentration of such networking experts. The casual, ask me anything, tone was set specifically to disarm the frequent, negative posters who frequently post without contributing to the discussion in a meaningful way. At this moment, I have now signed up 249 people for the Switchboard beta (thank you everyone, we won't let you down). Thanks for your post.
Interesting, thank you. In general I think the trust/privacy issues are bigger here on Slashdot than they are in the rest of the Internet (I submit Facebook's success as evidence). I think the subscription part was a bigger deal to more people. That said you clearly have a valid point, and your stories about those other products are clearly nightmarish. I'm going to keep this in mind going forward. And I get that nothing I say here will make you trust me. So are there standards/trusted 3rd parties, whose seal of approval would make you believe in our security/trustworthiness?
Thanks, Chas.
Thank you for asking. Yes, so in the new form, we're pushing it largely as a personal VPN. It's very easy to setup, and automatically does the same sort of firewall traversal (STUN, TURN, different ports, etc.) that Google Talk or Skype does to get through a firewall. So you can get a VPN server setup without having to deal with port forwarding on your router, or anything like that. We are smart about our channel bonding and protocols. As long as it's possible, we'll use UDP and get much better speeds than you would get with a TCP based solution. It does have the multiple Internet connection stuff going as well. Yes, for that to improve your performance, you have to set up your server somewhere with a very fast Internet connection. There are a lot of situations where this comes up: places where DSL is still common, and where you have a very mobile workforce, a lot of times people have access to both Wi-Fi and 4G or DSL and 4G.
Thank you, good feedback. We're going after the personal VPN first, but I think that eventually we'll be able to return to the cloud server. There certainly were a fair number of people who really wanted it.
Linux will be a supported platform for Switchboard. We did a much better job of building cross platform C++ with an HTML user interface from the ground up. Dispatch's a code has a lot of Windows specific stuff throughout it, the port would have be a new development effort almost from scratch. So I can't really say if Dispatch will really ever happen on other platforms (it could but... not soon, anyways).
I felt like a lot people started off negative, but when I started actually answering, everyone seemed really well behaved. I was happy, I think that maybe more people from the stories should just jump into these conversations. In the end, I didn't have any bad "troll" experiences.
Chocolate.
Ok, what the hell. My father is Evangelos Gizis. He's an academic, who among other things has done stints as the President of Manhattan Community College, President of Hunter College, and Provost of Queens College. He still wishes I had taken school seriously and gotten a PhD.
More and more, I'm coming to think of myself as a guy who takes complex networking technology and tries to make it simple. I'm doing this because I want to give people not only faster internet access, but also free them from the companies that would control what we can do on the Internet connections that we're paying for. Well that's my big vision, mostly I answer emails, and wish I had more time to actually code.
I do get how unbelievably negative Slashdot can be. Take the first Slashdot story that ever covered Connectify. ... What did I get 200 comments on Connectify, probably all negative. But I got 20,000 downloads of the software in the 8 hours after the post went up. So it's not obvious from reading the discussion but there actually were 100x as many people who liked the idea, as hated it. (Oh and then we decided that this really could be company).
Sorry, you're right. Here's what changed: Originally this was going to be cloud based service. We'd have servers all over the world, which would aggregate your connections for you to give you faster Internet. But people wanted to run it themselves. And once that happened, we realized that we might as well make it clear that Switchboard is really a VPN. So once you're running your own server, you can start sharing resources off your network with yourself, wherever you are.
Ok, I got a little dramatic in the title of the post. Body is accurate though, I really did get a lot out of the discussion here. People thought it was just a load balancer, and everyone was very wary of yet another subscription. It was real feedback that helped explain a lot about what was going on with the campaign.
Absolutely, that was the main scenario we were thinking about as we designed this. It does a nice job of putting links together so you really can a skype video call from the hotel. Since then we've been amazed to find out how many other scenarios there are: people with 2 DSL lines to the houses, business disaster recovery scenarios, people needing to get video streams into or out of areas where they can only get 3G service... the list keeps growing. But yes, the business traveler was who was in our mind at the start.
If we get a packet but haven't yet delivered the previous one in the sequence, we hold onto it until we either get the missing packet, so we can deliver what we have in order, or until we've seen a packet come in on all interfaces, and can declare the missing packet as lost, and then deliver everything we have.
Look at our typical scenario: two ISPs, let's say 7Mbps DSL and 10Mbps cable and latencies that differ by, let's say, 20ms, with careful reordering you can see single-socket performance of about .95*(10+7) with average packet latency somewhere between the two. Without some careful reordering, TCP is very good at slowing way, way down, and a lot of UDP media streamers just fall apart completely.
If you're us, and you get a packet but you haven't yet delivered the previous one in the sequence, the right thing to do is to hold onto it until you either get the missing packet, so you can deliver what you have in order, or until you've seen a packet come in on all interfaces, and you can declare the missing packet as lost, and then deliver everything you have.
As far as SACK and D-SACK, you don't really want to do that for the 30% of your packets that arrive out of order. From what I've seen in the real-world, those RFCs are not intended for coalescing streams where potentially a lot of the packets are out-of-order (as they would be in the DSL + cable example).
Thanks again for your interest.