 Yo, thank you. I'm Martin Schein, and I'm working in a genome labs in the U.S. for the next few years. And today I want to support users of the network in genome to say everything that you can do between the micro-colonel and your web applications. So, generally, genome is like a building block system. You have a lot of building blocks, and you put them together to your individual solution. And so there are some building blocks that are for network. You will know today. The first chapter will be a big picture of all the components, and then we will orient them there in this picture through the other chapters. The first is about the drivers that we have, and then about the controlling tools. So, say, tools that are used as interception tools for the networking session that we have on top of the drives. And then we speak a little bit about what front ends exist and how this is implemented. And at the end, I will give a little motivation for applications and look on applications that already exist. So, first, I have separated them as set in four layers. You have these drivers. We have the main drivers that now exist. And they support, they use the device IO that is provided by the core of genome and all generic interface, the next session interface. And with this next session interface, you can do all the controlling stuff. You can do routing, you can do encryption, and other things that you want to do, bump in the wire between two new sessions. And then, at the top of that, you have this front-end layer where you adapt to your application, what the application needs for specifications. Let's start. I will also go a little bit into the history of the components. First, the wired NIC driver. In general, we had the first place of the Linux NIC driver, especially for the PC net parts of R&D in the year of 2009. But this was mainly for the community and compatibility. And later, the rise that we need some support for actual hardware that is built into laptops that we use. So the laptops that we use had almost all these new 1,000 series of Intel built-ins, so we needed some more support. And at this point, it was a good option to go to the GPXE project to look at this code. GPXE is like a network bootloader project that is the successor of Apple. And it is a pretty small, slim framework. It is easy to port. And so we switched to this and had them support for the internet network codes. In the year 2011, we discovered that the GPXE sources were a little bit inactive. So there was not much activity by the developers. And so there was the official successor of the GPXE project, the IPXE. And we took a new project to this and we switched to these new sources. So we are more up-to-date and can support for new codes. And we will see. Okay. There's also a new support over USB. You can use. This is supported from the Linux sources. We use it especially for the eSports here, the XMS5 source, the eMap 4 source and the Broadcom source. Because we use things like the motherboard, the Android board, and Broadcom's Raspberry Pi. So there you need a network of USB. Okay. We go on with the Wi-Fi driver. The Wi-Fi driver was initially the port of the MedWi-Fi port of Linux and enabled us the FRS chip sets, especially this one. These ones that are listed here. Yeah. Over the years, we came to the place that we wanted more of these Internet Wi-Fi cards supported. And this was enabled with the port of IBM Wi-Fi. And we took this as an opportunity to report also the whole Wi-Fi state of Linux and the VPA is hard to get because with the MedWi-Fi we had no protection, for instance. So, yeah, only unprotected Wi-Fi. And yeah, this was quite some work. I think it took about six months also to get this one store of a code base ported and regulated. And, yeah, what came out is this Wi-Fi driver component that works as follows. We have a short overview. The Wi-Fi driver component takes an active PCIe session before the device, of course. And then you have some wrong module that you get in. And this wrong module contains at the beginning, it contains the red line that you want to connect to or it contains nothing, I mean empty too. So, the Wi-Fi driver then scans, of course, the red lines that are available and it provides to you a report. This is like a file but it's not really the same but it gives you in this report a list of all available Wi-Fi's so you can connect and you can choose from these ones and these ones. And it also gives you information about signal quality, protection types and so on. And if you have not configured yet this Wi-Fi inside the VLAN configuration, you can now put it in and it tries to connect. So, this VLAN configuration, the Wi-Fi driver always, all the time, listens to this VLAN configuration and all the changes tries to reconnect to the Wi-Fi you configured in here. And the end product of that is the report VLAN state. In this VLAN state, you can see if you are connected and to which Wi-Fi you connected. And, yeah, I can, hopefully, yeah, I can show this to you, of course. In my scenario, this is a run-on link. There we have these access points. The access points listen for the wires. The state shows that we are successfully connected with the cross-email of the two ICs. And here we also, the next thing is the signal. It's a link loopback. I have not much to explain about this. It takes a next session and provides a link session where you can put something in because it's not highly sophisticated. Okay. We go into the controlling tools. Maybe the first thing that was in the queue was the lift bridge. The lift bridge implements some flavor of the proxy art protocol. It monitors the output on the ARP and the DHT that goes on in the next sessions and tries to get the mapping about the clients that are connected to this. And that is this, like, an OZ layer of research. So what you have is it has one uplink at the downside at the bottom. Multiple clients that can connect at the other side and you can, I have a link to the lift bridge to collect this information. These relations between IP addresses and MAC addresses. Or you can also configure it so you can say this one, Nickline one has IP address and so and so. And the MAC addresses are allocated for each client. So it creates some virtual virtual MAC addresses for each client. And then the forward packets can come from the uplink or from our clients according to their destination IP addresses. Okay. Now for the Nick Rauter. Nick Rauter is a little bit started with a pretty small, a small set of features that we wanted to achieve in this project. We wanted to create that. And it ended up implementing a whole level three, level four routing component that now knows routing for IP for four, can also do a night, of course, for IP for four. And we have all four routing for IP for four protocols. Yeah. In the past we had also the problem that we wanted to do DHCP. We wanted to have DHCP for the single domains of the Nick Rauter. And originally the plan was to do DHCP outside of the Nick Rauter and to do an extra component and then re-contact on the Nick Rauter. But for the first step we thought it was nice to have this DHCP inside the Nick Rauter because it's not much code, actually. But yeah. This is where maybe get outside the Nick Rauter to an extra component. But there we would have to do an extra component that manages the re-configuration of the Nick Rauter. Yeah. Then the Nick Rauter can also show you a quite big log of all the packets that go through DHCP and have a really good insight into what's going on in your virtual networks and who is communicating with whom. But of course this is also a little bit bloated not all the time you want to see all the packets. But it's cool for the bugging. And also it can report statistics to the outer world. So it provides a report file and this report file and such things like how many packets go through one domain, how many were sent, how many were received and so on and so on. How many fakes there are. And yeah. And this is over the function of Nick Rauter. So you have several domains. Each domain is like a set of rules. To each domain there are these rules and the DHCP will all connect it. So in general you could say that the domain is like a virtual network and a virtual subnet. And to each domain there can connect multiple Nick sets. And the update of the Nick Rauter is not special in this. It's also only a domain. And what we have here, the only difference what we have here by now, the update is the only domain that creates a session. That is the server for a session and the client for a session for Nick's session. It creates normally a Nick's session to the driver or to whatever the network of physical subnet. Yeah. So far. Okay. I can show a short example of this. Because in the scenario I'm using there is also a Nick Rauter and it manages the different applications that I have now running and you can see here this is the configuration of the Nick Rauter. We have several domains, and there are several rules like here we have for TCP or UDP, we permit any for in this case or we want to fit all for a specific subnet to reroute to socket at best and so on. And we have here the DHCP server configuration of one domain so we have the DNS server, I can use them and so on. Yeah. And you can also see here that you can I will go with a static configuration of the Nick Rauter's IP configuration for the domain. Or you can tell the Nick Rauter its own configuration over DHCP so it will play at the uplink DHCP client and get its own configuration as well. Yeah. The Nick dump, this is a simple component that is abandoned wire component for we put it between two Nick sessions and it shows us all the traffic that goes through so it puts out a lock for the packet headers of these protocols that are listed here by now and you can configure the detail of the lock and you can also switch on timestamps. Okay. Three, four. I think everybody knows four. It's a project that aims for anonymize DHCP connections of our so-called onion routing so it uses several four nodes in the network to reroute a connection into an anonymize and I think three years ago or so of the version it was an earlier version first like zero to four or so and yeah, we are not so far away from the latest version but this is an experimenter. We don't test it that much. It works as far as I can tell I tested it yesterday and it comes up and it can connect to the network and it gets a great deal but there's one demo scenario you can try. It's an eigencore run in the word repository and this would try to fetch over the talk so what we do in here is essentially we take the nicoldom again and we have the fetchaway and the other domain there is the Tor and we configure the fetchaway domain in such a way that it can only connect to the Tor domain and to the Tor for the 1950 and so all the traffic of the fetchaway must go over the Tor and the Tor then has access to all the free internet over the uplink so you can ensure that you won't go unsecured with applications that you don't trust Next, OpenEVN With OpenEVN you can turn it into a virtual app and it networks and this goes again bummed in a while so you have one link section at the one side one link section at the other side and it works transparently so yeah I don't think I have to explain this much we have ported version 234 and this is 244 I don't know there is some focus in work but it's experimental so we don't test it that much but I know that there are guys that work with this and it's not abandoned in this way but you have only the bridging mode so you can only do FNM okay the font and tools first I will go into the stack stack we have and how many we have dspipstakes initially the initial stack we have for dspip was the library IP stack it was ported as look so you can link it against each component it is accompanied by an xc plugin so we have in geno this concept of the libc like empty in the initial stack and you put some plugins behind it that fulfill your needs your environments and the lightweight IP stack libc plugin is such a plugin that you can put behind your libc and then you have the lightweight IP that is functionality so this way you won't have to incorporate the whole libc in every component just because you need one functionality in 2013 we started experimenting a little bit with pigabit network and then we discovered the lightweight IP stack is not so cool when it comes to performance on pigabit network so there was the approach to go to the dspip IP stack of linux 2 so the dspip stack of linux has the advantage that it focuses much on optimization but the drawback of this is of course it is a pretty big and it needs a lot of interfaces so you have a lot of porting work, a lot of internet work but there is better performance so we have now there is both of these stacks weighted as libraries and you can choose if you want to have a slim stack or if you want to have a stack that is good in high performance this is the rival old picture of our boards with the stacks you have unique sessions and on top of that you set this lightweight IP plugin for the lightweight IP live and then you can have of course here the dsp atop of this and then your application ok let's go a little bit into the history of vfs without this x because just to understand why we did this the thing here is vfs is of course tightly for one of the main features of linux 3 that everything is a pilot you can put everything into a virtual pilot system and then provide it as pilots and the other side the other side we have this genoad world where we don't want to have such being like a global namespace and all the rights that come with it all the privileges we want to tailor the privileges of each component according to their requirements and to forget about the best of both worlds together we have something like nukes one time one of his main features is the vfs implementation we implemented the vfs in this and it plays like its role is a little bit like the clue code between all the sessions that we have in the genoad and the fire API for the linux programs for Linux applications so at some point we discovered that it would be nice to have this vfs extracted from nukes to use it also in other applications to have a nice generic interface we talked to regardless of which session you want which resource you want to speak to on genoad so we had this vfslet and we created the libc backend to combine the vfslet and then we put we put in each application especially pilot vfs instance so what you can do with this is you have like normally showed in the demo in the other presentation that you have the root tree vfs somewhere in this basic setup and then you can give parts of this to other applications and they only see these parts of the vfs in their environment and can call it with the libc on then this is what we do when we go to linux there was the need also for this so you could provide one vfs to multiple applications at the same time and you can see how this works here we have one server component that has the vfs library linked to it and then we have multiple plugins connected to it at the backend the log plugin at this point for example enables you to write to the log like it is done this right side and the round plugin for example can access images of geno so you can put them as strong modules in this file and all this goes to the front end it's always the same file session now there was a new question at this point years ago we wanted to use this text that we had we wanted to use such text with multiple applications so you have one mistake only and you have multiple applications that access it for instance when you have not so much API address as something like that you don't want to redo all the IP context so phcp like that then how would we do this and of course the simple approach would be at this point to introduce a new geno session and socket API session implement a dedicated multiplexer component but this would be pretty specialized and not so reusable so we thought about an annoying system and this was why don't we integrate this whole stack into the vfs server and so the functionality of these stacks would be provided over files to multiple clients so the clients would have to speak only with the file session interface and at the back end it would be translated to network packets this is the concept of course we have something like the Linux IP plug-in for the vfs library and then you have your vfs server again and the file system session at the top of it and yeah how to get this like you have the Linux IP plug-in for the vfs creates a directory structure where you have this socket directory and in there you have this information provided through files that comes from your vfcp so you can read all your data and you can also create new sockets by going into this pcp directory for example and write your a read from new socket and what you get there is then the name of the socket and when you do this the Linux IP plug-in creates a directory with the name of the socket and then in this directory you have new files that are in principle the controller commands that you normally need to interact with the Linux IP stack and you can write for example to bind or connect with the informations that you want to write you want to connect and then the Linux IP stack would in the Linux IP plug-in would translate this to a re-connect in the Linux IP stack ok and then when you have accomplished the connection of course you can interact with local and remote and send data over ok and of course the top of this you can have then and type session plug-in for the Linux IP and so you can talk you can use in the US case unmodified unmodified applications that talk with the Linux IP that are built upon the Linux IP short overview of applications that run on top of this so we have seen already virtual gox that runs on top of it that runs directly on the next session to create a virtual device for its guest and we have our components like those books for games or stuff like that or the edge server-like that run read with the socket API from phillipsy and then we have these disciplines that this is brought to the S plug-in file system session to do the best power server and so on ok and of course we have the Skype scenario that was already presented today where we have this runtime in it where I can start an arbitrary runtime that I want to use for my daily work and in this runtime I can have for example Exibundo virtual box Exibundo guest in a virtual box or Tiny4 in a virtual box to connect directly to the next session of the micro-outer or then I initially wanted to present here to HTTP servers that I can talk to only over the Tiny4 so I can do connection only in the Tiny4 to these two through the VSO but unfortunately I had some problems with HTTP servers so yeah this doesn't work that well but in general you see here this was this micro-outer I have showed the configuration some time ago and you can have now live here this one virtual box it goes like a micro-outer connect some websites why we have the other virtual box with my Exibundo and here I can also bring two websites so it's it's multi-plexed over the micro-outer in the scenario that I'm using so that's for my part now there are any questions in this one you said Linux is there is there one reason for this or may the question was is there a reason to what I said that the LXIP as far as I understand the way that the LXIP has more possibilities more opportunity and more opportunities to tune performance to adapt to the device so when you come here to check if it's working close the door just get more out of the device so excuse me wait a little bit the question as we could also add this stake of course but we don't mind this solution so far and the other side is of course if you would add these opportunities to the LXIP I don't know we haven't took this approach we have brought the LXIP stake to get this performance I guess I do I think people need that performance so they will have to but we don't do it this way maybe maybe some the other guys are more familiar one thing is certainly the performance because I'm not entirely sure but I think the LWIP stake doesn't implement any secret new scaling just attached for the sentiment or the other way around so that it doesn't adapt the window sizes dynamically to the performance but in case of LWIP it was LXIP LXIP features more options so you can there were some use cases where we needed some functionality that wasn't implemented in LWIP and that's one of the other reason why we choose to put a stake that is more more sophisticated features LWIP has seemed to have less latency than Linux than LXIP but of course it's a trope so there's sort of trade-offs of different characteristics I think that's what you said Joseph we just didn't do the implementation for our features into the LWIP stake but instead and during LWIP stake we know a lot of things and had a lot of experience in the chest that won't have the resource and the time to do it and that's why we choose because inside LWIP LWIP doesn't have we choose to go this way and have two states with some customers planning plans and wants we can choose with them but there's no preference for us so maybe it ends up for you that you are not so much the expert in this I just wanted to repeat it for the microphone so the question is are we able to pass data through these different layers without the copy and the answer is no for more security reasons if you are imagine you are in a cloud and you have these different packet streams that are going on in different domains you don't want to trust the guys that use these shared memory and essentially it's shared memory between the client and me and even if I'm in an untrusted domain and would say okay I take the shared memory and forward it to the other domain that is trusted in some way would be unsafe because I can take away the shared memory from the first time in a different way so it comes with the principle of security but you can't do it without the copy I hope this answers your question I wonder when I got that right in the nick bridge you virtualize on a layer 3 why you choose that instead of layer 2 virtualization when you call it a bridge and then also have the rooter do layer 3 the question is why do we call it a nick bridge why it is virtualizing on layer 3 I don't know if this answers the question but I'm referring here to the OZ layer 3 so it's in IP the reason is why you have two ways to virtualize on an IP level I don't know what the name at this point is maybe a little bit misleading I don't know it's essentially a switch and you the functionality is the out proxy for the bridge in general so don't let yourself be misleading by the name that much yeah so