Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I completely agree on the design. I'm working on a big web design rev right now that looks much better.

I'm not sure what you mean by diagrams though. This doesn't work that way. It creates virtual networks that look completely flat, as if you and every other peer were plugged into the same Ethernet switch.

One of my difficulties has been getting this across... you don't have to think about topology. It's easier than that. It's a virtual switch. Install, join network, done. Everything is automatic.

You can peek at the new design here (but don't try to use it): https://test.zerotier.com/



That design is a lot better. But I'd still recommend you look a little more at some professional themes. Also the logo could use some typographic love :)

But a network in which every peer is connected to the same ethernet switch isn't flat, it's a star. But a star network doesn't scale as well as you claim.

Behind the scenes to make it scalable perhaps you build p2p connections, this would make the diagram be more like a complete graph, which it has its own scaling problems.

To solve it, perhaps you have stateless or on-demand connections, so the actual number of connections is lower than the worst case. Or perhaps you promote peers to super-peers and build a stars of stars network.

A couple of simple diagrams answer these questions and quickly let me decide whether your solution is suitable.


It's all three of the things you mention: peer to peer, stateless, and on-demand. It also uses UDP, so it's not opening huge numbers of TCP connections. The only time it uses TCP is if you can't use UDP -- as a fallback mode.

I'm not sure why that wouldn't scale. Even if you had millions of users on a network you'd only be connecting to those with whom you're communicating.

It is also as you mention a star of stars network. The supernodes are at very high bandwidth sites and their number and size can be increased on short order. They only relay data if P2P/NAT-t fails, which only happens for about 1-2% of users. Otherwise they just shepherd NAT-t. They're geographically distributed for high performance: Singapore, Tokyo, San Francisco, New York, Amsterdam, and (soon) Sydney. If a supernode fails it takes 10-30 seconds to fail over.

I have plans to further decentralize and add automatic promotion of nodes at some point in the future, but that's a hard problem that requires more study.

Edit: this isn't just another VPN. This is the result of over four years of work, including a huge amount of research into networks and cryptography. It's a completely new system.


"It doesn't scale!"

Who said it needed to scale?

How many Facebook friends does the average user have?

Do these these networks need to be larger than that?

If users want larger networks they can bridge their VLAN's.

"I don't like your logo!"

I'm using a text-only browser so I really don't care what your logo looks like.

Keep up the good work and ignore the critics.

Suggestion: Make the crypto fungible, so if a user wants to use a different library, e.g., NaCl, they can.


Heh.

Actually, thank you to the previous poster. I didn't mind the criticism. His point -- "your existing site doesn't look good enough to convince my boss" -- is very valid. The new site looks a lot better and it's not done yet.

It does in fact scale pretty darn well, mostly due to the fact that it's connectionless, stateless, and opportunistic. If you're on a network with ten million people but are only talking to ten, you'll only be sending packets to/from ten.

The supernodes have to know about all ten million, but last I checked that wasn't very much memory... maybe a few gigs tops? So that's what, $20-$30/month per node? Or I could add the ability to put a real database under it and use SSD cloud nodes and handle billions of users with sub-10-ms lookup latency.

Of course if I get that many users that'll all be in the good problem to have category and I'll have plenty of money to scale out and if necessary improve the protocol/architecture. There are many directions I could explore: M:N supernodes with load balancing, various other sharding techniques, moving to beefier cloud providers, further decentralization in the protocol, all of the above, etc. I could set up big labs, run simulations, do all sorts of cool stuff. I've done enough so far to convince me that the problem of monstrously scaling this thing is very solvable. Just have to do the work.

I'm not making the crypto fungible. The protocol does have flags that could be used to indicate new algorithms if upgrading the crypto becomes necessary, but I have been an absolute simplicity nazi with this thing so far and will continue to be.


Interesting projects. What role does the website/service play wrt to the clients? Is it possible to run fully separate networks with just the client?

Any thoughts of how it compares with i2p? (http://geti2p.net/en/)


You could technically set up your own completely separate network -- everything you need is there. You'd just have to fork it. It'd be kind of like forking Bitcoin to make Dogecoin or JuggaloCoin or whatever. But in this case I wouldn't see the point. You wouldn't be able to join networks on the "real" network, etc.

Compared to I2P and Tor: it's neither of those. This is about network virtualization and making it easy to set up ad-hoc networks across physical boundaries. It's not a privacy tool per se, though it is end-to-end encrypted so the content of your data is hidden. My goal isn't to duplicate the work of Tor or I2P-- if you want strong anonymity, use those. (You could use ZeroTier One through Tor, though it would be slow.)

There is an incomplete beginning to a technical FAQ here that answers some of these questions in more detail:

https://github.com/zerotier/ZeroTierOne/wiki/Technical-FAQ




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: