-======================================================================================================-
| David Irvine - SAFE Network, Technical Overview of CRUST - Full Transcription (Clean) [beta 0.5.0.1] |
-======================================================================================================-

So CRUST is a really good library actually, and it does a lot for us. In the last sort of thing we were talking about---Routing and Routing's relationship with CRUST---it was kinda making it clear to people:

CRUST is an IP layer thing. It knows nothing about anything above it. And it knows nothing about Routing IDs. It knows nothing about what we are trying to do with it, or anything like that. So CRUST is an IP based solution. And the idea of the CRUST is: it's for P2P networks. And that means, if there's a P2P network somewhere, and all of them have got their own addressing in Routing mechanism (all P2P networks have). So CRUST sits underneath it. And gives it the ability to communicate.

So the nice thing about CRUST, where we want to see CRUST is basically that we've got some kind of network, here. And CRUST is sitting here, and just connects to that network. So it says, "I'm connected to the network."

And importantly it's just connected to anybody. It doesn't care who it's connected to. It just says, "I'm connected to the network. I'm probably connected to people that you don't really want to be connected to. And you're going to ask me to drop these connections, and create new ones. But my job has been to connect you back to the network."

So at the very bottom layer, at the IP layer, CRUST has said, "OK, you're connected. Now what do you want to do?"

And for us to be able to use CRUST, we have to know some kind of way to start it, and for it to tell us, "Here's their connections." So we just need to know what connections do we got? You got some maybe like TCP thing, and maybe some UTP, and maybe some other stuff, maybe some [??]. So we just need to know what we're connected to in the network.

And for us to have a connect, where we want to connect to some person, with a portal, and an address. And then we want to know if we've lost a connection. And we want to know if we've got a connection. We really want not much more from CRUST.

And what we don't want to do, above the CRUST layer---the things that we don't want is we don't want to know anything about Bootstrap information. We don't want to know anything about NAT-Traversal or otherwise. We don't want to know any of that sort of stuff. So what CRUST is basically saying, "Don't you worry about all these things in red. I've got them covered. I'm going to do all that for you." So all that you need to know is, "I can get back into the network."

(It can tell you that you're connected to a couple of guys. It's up to you to chat to them and do some other stuff. And you can connect to other people. Obviously, send messages, drop connections, and things like that as well.)

But CRUST just is basically saying to us, "We'll take the headache of all of that stuff---of all the Bootstrap stuff, all the connecting to where you are---off your hands." And that's really what we want CRUST to do. And how it does that is... we'll just over to [??] [??] actually, hahaha.

How it does that is it's obviously going to have to keep a Bootstrap file. We've got (it), so that we can connect remotely. So we can connect to some guys remote. We've got a Beacon, so we can connect on LAN. Connect LAN or local PC. So these are the ways that we can want to be able to connect back to the network.

And we have to consider that there might be no Beacon. There might be not in the PC. They might be not in the LAN. So the Beacon might fail. And we might need-- we must Bootstrap then. We must try and Bootstrap. Or we are node 1.

So just looking at CRUST from its very foundation, we are saying to CRUST, "If there is a network, you must connect to it. You must connect to that network." So when CRUST first starts, this is going to be empty. There will be no Bootstrap file, and nothing for it to connect to.

So the very first network on a P2P network from CRUST's perspective---let's call it Crust 1. It's going to have no Bootstrap file. It's one of the nodes that we've started that we have to connect to. And we might have several of those.

And maybe these are, what we have is hardcoded nodes. So these are hardcoded nodes. So what that means is these nodes, for users of the CRUST library, you should pass at least these nodes through to the Bootstrap file of CRUST. So if you've got some hardcoded nodes, these are also nodes. This means we have to be able to pass to CRUST: Fixed Listening Ports. So that if those things restart, they restart on the same port that we originally had them on. And that's OK. That's pretty straightforward.

So we need the ability to have some hardcoded nodes, and to be able to pass these hardcoded nodes either through the CRUST API, or install CRUST with a Bootstrap file that's got those hardcoded nodes in it. If the hardcoded nodes are in the Bootstrap file, we should identify them as hardcoded, because of the way that the Bootstrap file should work.

So the Bootstrap file itself should work like this: If CRUST connection is 'direct' (and I'll say direct; we should come up with a word for direct)-- if we can get to that connection via more than one CRUST node, then we can send it direct. Then put in Bootstrap. Then Limit Bootstrap to 1500 Newest nodes. So we always want to have the Newest nodes.

And that is why we want to identify hardcoded ones as different. We either pass the hardcoded ones through every time, through the CRUST API, or by identifying them in this Bootstrap file as something different. I.e. they don't need to be the Newest nodes there. So the Bootstrap file is really important. The ability to hardcode or pass through the Fixed Listening Ports to nodes is really important for these guys here.

Not only these guys---there's another situation where you want to be able to pass the listening port through. And that's where people have port-forwarded on the router.

So if you've got TCP or UDP, it doesn't matter. You can always port-forward on the router. So if you've got TCP or UDP on your router, you can say, "Port X should go to IP Port." And IP being a local IP on the network. So you might Port 8080 always goes to 192.168.0.1:80 (just 80). And that could be TCP or UDP. It doesn't matter. So in that case as well, you want to be able to pass a Fixed Listening Port. Because, after you've port-forwarded something, you don't want to then change the IP address here. Because you would have to get into the router and change the table again.

So these hardcoded endpoints are not the only reason to be able to pass through the listening port to CRUST. So that's pretty important.

And just getting that right means that CRUST should always be able to connect back to the network it's supposed to connect to. (Unless there's a dramatic thing, like you physically aren't connected to the Internet. The router is off or something like that.) So that gives us an ability to connect back to the network we were on, which is pretty important.

The Beacon gives us the ability to quickly create test networks. And if we're using a local machine or a local network, it gives us the ability to test all this stuff really, really easily, just by switching the thing on and not doing anything else.

So in terms of protocol handling, we've got TCP. And we've got UDP.

So we need to make it connection oriented. TCP's OK, and we switch to UDP for that. Then we need to have a NAT-traversal. So NAT-traversal, what we do here is hole-punching. And that's where we use a rendezvous connection, or just a connection with a longer time-out than usual.

NAT-traversal with TCP, we've got uPnP. And for uPnP we can actually take the Rust Bittorrent library, and it's got a uPnP file. And we can just put it straight into our thing.