[00:00.000 --> 00:13.000] Tell me when, tell me when, five more seconds, okay. [00:13.000 --> 00:20.000] This time silly it makes the video of cutting process so much easier if we stick to a schedule. [00:20.000 --> 00:25.000] Good afternoon everybody, thank you for having me here. [00:25.000 --> 00:34.000] Let me start from a short introduction of what internet of threads means. [00:34.000 --> 00:37.000] What is an end node of internet? [00:37.000 --> 00:42.000] So, which are the communicating nodes of the internet? [00:42.000 --> 00:49.000] The legacy approach, what is at the beginning, it was the internet of hosts. [00:49.000 --> 00:56.000] Internet of threads were given to controller, to each controller. [00:56.000 --> 01:07.000] So, actually the communication took place, takes place between the controllers of hosts. [01:07.000 --> 01:29.000] This concept has been made wider and the networking, the network endpoint are virtual controllers of virtual machines or even in spaces. [01:29.000 --> 01:44.000] Internet of threads is one step farther, it means that we want even just processes or even threads within processes as nodes as internet. [01:44.000 --> 01:56.000] So, the idea is to give IP addresses, actually IPv6 address we wouldn't have as many IPv4 address as we need, to threads or processes. [01:56.000 --> 02:00.000] The idea can be depicted from this. [02:00.000 --> 02:09.000] Long time ago there were fixed line and really the telephone number was connected to a place, a room. [02:09.000 --> 02:15.000] And it was common to call a number and say, is Jack at home? [02:15.000 --> 02:27.000] Nowadays we use portable phones and the numbers are connected to people and it's very easy. [02:27.000 --> 02:33.000] So, on the internet what do we look for? [02:33.000 --> 02:36.000] We don't look for controllers, we look for services. [02:36.000 --> 02:53.000] So, the most natural way is to have IP addresses connected to the process with providing that service, not controllers or machines, virtual or real. [02:53.000 --> 03:03.000] An ether stack is just a layer between API to the application layer and the API to the data link layer. [03:03.000 --> 03:09.000] Actually these are two layers, layer three and four of the other stack. [03:09.000 --> 03:15.000] But anyway it's a slice in the middle. [03:15.000 --> 03:29.000] This implementation is currently most of the time deeply inside the kernel of the machine of the computer you're using. [03:29.000 --> 03:42.000] But it can be seen as a library and this library can be linked to a user process. [03:42.000 --> 03:56.000] And in this way the user process can directly, can talk with the network. [03:56.000 --> 04:12.000] We created, we made one further step to this implementation using the Libyot library for the Internet of Threads. [04:12.000 --> 04:29.000] It's not a library that implements a stack, it's a framework library that allows to load actual implementation for network stacks as plugins. [04:29.000 --> 04:46.000] Providing a unified API to the applications, in such a way it's possible to run applications that can use either the kernel stack or any implementation of the network stack as a library. [04:46.000 --> 04:58.000] Actually the actual implementation permits to change the implementation just by changing a string. [04:58.000 --> 05:05.000] The actual stack supported by Libyot are the kernel stack. [05:05.000 --> 05:09.000] Woody stack which is actually a trick. [05:09.000 --> 05:15.000] It's a namespace using a top inside the namespace. [05:15.000 --> 05:33.000] So we are borrowing the kernel stack using it at user level, then a real implementation of user level TCP-IP stacks like Pico TCP, the module is named PicoX. [05:33.000 --> 05:44.000] And the working process where I'm working to port lightweight IP to this port. [05:44.000 --> 05:51.000] Okay, what do we need in the API? [05:51.000 --> 05:58.000] The way to communicate, this is quite known and this is the standard way we use the stack. [05:58.000 --> 06:01.000] So open-closer communication point center. [06:01.000 --> 06:05.000] For all these, there are backlit sockets. [06:05.000 --> 06:12.000] But what is not common using the, if you use the kernel stack, [06:12.000 --> 06:23.000] you have as guaranteed as provided the definition of the stack as a configuration parameters of the stack, [06:23.000 --> 06:30.000] like which is the API address, which are the routing definitions and so on. [06:30.000 --> 06:39.000] So we needed to add this port for the API. [06:39.000 --> 06:51.000] The definition of stack needed some syntax, some specific syntax. [06:51.000 --> 06:58.000] When using the API, a new stack is created. [06:58.000 --> 07:05.000] There is a, it's a pointer to a specific structure that can be used for communication. [07:05.000 --> 07:15.000] So the only difference for socket unit, for the socket API, is that instead of using socket, [07:15.000 --> 07:20.000] there is a new call named mSocket, which has one further parameter, [07:20.000 --> 07:25.000] which is the actual stack implementation to use. [07:25.000 --> 07:37.000] Okay, and then there are all the other API calls well-known from Berkeley sockets. [07:37.000 --> 07:47.000] But okay, we needed to create and delete the stack, so in such a way to do that, [07:47.000 --> 07:57.000] we use those calls we have seen two years ago, and the pointer can be used for communicated. [07:57.000 --> 08:00.000] And what about configuration? [08:00.000 --> 08:11.000] Okay, for configuration, there is an NFC used, for example, [08:11.000 --> 08:21.000] by the Klinus kernel that uses the other family netlink to provide messages for configuring the network. [08:21.000 --> 08:31.000] So there is no need of further API entry for configuration. [08:31.000 --> 08:44.000] We just need to, we just need that our stack support AF netlink configuration. [08:44.000 --> 08:51.000] Another point about these sockets, using forum sockets, [08:51.000 --> 08:57.000] if it's a library level implementation of the stack, [08:57.000 --> 09:07.000] the problem is that this integer could be an internal number of the library. [09:07.000 --> 09:12.000] Instead, we need that integer to be a real file descriptor, [09:12.000 --> 09:20.000] because we need the file descriptor to be used, for example, for Paul socket. [09:20.000 --> 09:36.000] And we had to write a new kernel module in the library named Paul, [09:36.000 --> 09:42.000] that creates a file descriptor in which the elements can be synthesized. [09:42.000 --> 09:56.000] And so stack implemented at user level as a library can provide real file descriptor, [09:56.000 --> 10:00.000] and this file descriptor can be used on select Paul and so on. [10:00.000 --> 10:05.000] So we can use real file descriptor, file descriptor coming from different implementation of the network, [10:05.000 --> 10:12.000] and write an end dreaming program altogether. [10:12.000 --> 10:18.000] Just a quick look to give you the feeling of what does it mean. [10:18.000 --> 10:27.000] This is a program just sending chow using a datagram. [10:27.000 --> 10:31.000] This is the legacy way. [10:31.000 --> 10:40.000] This is the same example using internal threads. [10:40.000 --> 10:42.000] Here is the implementation. [10:42.000 --> 10:48.000] Just by changing this string, I can use any implementation I want, [10:48.000 --> 10:51.000] provided I have support for that. [10:51.000 --> 10:55.000] Okay, now the core of the presentation. [10:55.000 --> 10:59.000] We needed an ecosystem around this idea. [10:59.000 --> 11:08.000] We needed a lot of stuff that we currently have in our support, [11:08.000 --> 11:20.000] in our tool set, but we need them implemented as internal threads. [11:20.000 --> 11:29.000] We needed calls to configure the network. [11:29.000 --> 11:36.000] These are not calls from the Internet of Threads implementation of the library Internet of Threads. [11:36.000 --> 11:41.000] These calls generate net link messages. [11:41.000 --> 11:54.000] So it can be used even for configuring the kernel stack from a program. [11:54.000 --> 12:03.000] Let us pass quickly through this. [12:03.000 --> 12:08.000] We need a library to a query for DNS. [12:08.000 --> 12:15.000] Why? Because using the celib implementation, [12:15.000 --> 12:21.000] it uses the kernel stack, [12:21.000 --> 12:28.000] and it uses the definitions in atc.result.conf [12:28.000 --> 12:33.000] and the string atc.result.conf are coded in the celib code. [12:33.000 --> 12:38.000] It's not possible to change even the file to be used. [12:38.000 --> 12:49.000] But we designed a named proxy for word cache, [12:49.000 --> 12:52.000] especially for the Internet of Threads, [12:52.000 --> 12:58.000] which are the characteristics of this DNS. [12:58.000 --> 13:05.000] It uses the Internet of Threads so it can use for the same queries, [13:05.000 --> 13:11.000] or for word queries, different stacks defined by the user. [13:11.000 --> 13:18.000] But at the same time, they can provide further services, [13:18.000 --> 13:28.000] further features, specifically useful for the Internet of Threads. [13:28.000 --> 13:33.000] Let us pass. [13:33.000 --> 13:41.000] These are the configuration items. [13:41.000 --> 13:45.000] But I prefer to show you some scenario [13:45.000 --> 13:52.000] in which the IOTNMD can be used. [13:52.000 --> 13:55.000] This is a common scenario. [13:55.000 --> 14:02.000] It's a common proxy scenario, like libmasque or similar, [14:02.000 --> 14:08.000] but implemented using Internet of Threads. [14:08.000 --> 14:16.000] So the idea is that if we ask the cache, [14:16.000 --> 14:25.000] if it asks the proxy an address provided by a friendly node, [14:25.000 --> 14:29.000] we can cache the result and provide it back to the query, [14:29.000 --> 14:35.000] or we can add some specific local addresses. [14:35.000 --> 14:43.000] It doesn't provide a relay from external queries. [14:43.000 --> 14:48.000] The point is that we have a stack for the query [14:48.000 --> 14:53.000] and a stack to forward the query outside, [14:53.000 --> 14:55.000] in this case, in this configuration. [14:55.000 --> 15:02.000] I provide the service to all the processes connected [15:02.000 --> 15:09.000] to this stack, and I forward the queries [15:09.000 --> 15:16.000] on another different stack with a different implementation. [15:16.000 --> 15:20.000] Okay. [15:20.000 --> 15:28.000] These are the tests just to see [15:28.000 --> 15:34.000] that it is able to resolve foreign and local results. [15:34.000 --> 15:38.000] Or it can be used as a delegated subdomain. [15:38.000 --> 15:40.000] Okay. [15:40.000 --> 15:47.000] So they did that given there is an S record [15:47.000 --> 16:09.000] providing, forwarding, defining this pink server as the responsible [16:09.000 --> 16:13.000] to the server, dummy, v2, and so on. [16:13.000 --> 16:18.000] So it provides back the solution. [16:18.000 --> 16:23.000] And here the new point is that we can use different stack. [16:23.000 --> 16:33.000] But I have kept some time to show you some more ideas. [16:33.000 --> 16:43.000] Actually, managing DNS servers for IPv6 [16:43.000 --> 16:49.000] is a daunting process, very error-prone, [16:49.000 --> 16:57.000] because if you have to write all those huge, long numbers, [16:57.000 --> 17:06.000] it is very hard to not to insert errors in the configuration. [17:06.000 --> 17:11.000] That is to create IPv6 address, [17:11.000 --> 17:16.000] the health part of the IPv6 address using hash code, [17:16.000 --> 17:23.000] hash resolution, using the result of a hash function [17:23.000 --> 17:31.000] defined on the full defined domain name. [17:31.000 --> 17:36.000] So given the full domain name, [17:36.000 --> 17:46.000] we can have the health part of the IPv6 address for free. [17:46.000 --> 17:51.000] So this is the proxy as in the previous example, [17:51.000 --> 18:00.000] but I can ask the server to solve all the addresses [18:00.000 --> 18:03.000] like something hash.local. [18:03.000 --> 18:10.000] And I can use any string before the hash.local, [18:10.000 --> 18:15.000] and I get a name resolution. [18:15.000 --> 18:18.000] That means that if I add a new node, [18:18.000 --> 18:22.000] which can be a computer or even a process, [18:22.000 --> 18:26.000] I just have to baptize it to give it a name, [18:26.000 --> 18:28.000] and it will be connected on the net [18:28.000 --> 18:38.000] without having to write any single line in the DNS server. [18:38.000 --> 18:44.000] The slides are on the website, [18:44.000 --> 18:50.000] so if you want to pass through and download the prototype [18:50.000 --> 18:59.000] from GitHub, you can test this. [18:59.000 --> 19:03.000] The same thing can be done, the reverse will run, [19:03.000 --> 19:12.000] so having a delegated domain that also addresses using hash. [19:12.000 --> 19:23.000] So we can have a number of local machines [19:23.000 --> 19:29.000] that can be seen from the internet just by giving them a name. [19:29.000 --> 19:34.000] But there is one more result, one more, [19:34.000 --> 19:38.000] which is one time IP. [19:38.000 --> 19:46.000] One time IP is a security feature like a one time password. [19:46.000 --> 19:50.000] One time password means that you have a password [19:50.000 --> 19:53.000] that lasts for a short period of time, [19:53.000 --> 19:59.000] so if somebody is able to ice drop the password, [19:59.000 --> 20:03.000] it's kept useless in a few moments. [20:03.000 --> 20:09.000] This is the idea of one time IP, the host part of the address [20:09.000 --> 20:14.000] is defined by an hash definition [20:14.000 --> 20:17.000] that changes during the time. [20:17.000 --> 20:21.000] It's an hash not only of the name, [20:21.000 --> 20:23.000] of the fully qualified domain name, [20:23.000 --> 20:28.000] but it includes a password and the time. [20:28.000 --> 20:33.000] So if the legitimate user wanted to connect to the server, [20:33.000 --> 20:37.000] it knows which is the actual IP address. [20:37.000 --> 20:45.000] Any other user, even if he's able to trace the network traffic, [20:45.000 --> 20:52.000] it gets some address that will be null in a few seconds. [20:52.000 --> 20:57.000] Okay, I think I have no time to show the other. [20:57.000 --> 21:00.000] Minus means time for questions, isn't it? [21:00.000 --> 21:03.000] Yes, four minutes left including questions. [21:03.000 --> 21:08.000] Just one point and then I go to the question. [21:08.000 --> 21:15.000] Namely, ACP is another tool which asks, [21:15.000 --> 21:18.000] which uses the ACP server, [21:18.000 --> 21:22.000] but these ACP servers query the DNS [21:22.000 --> 21:28.000] to provide the address to the computer, [21:28.000 --> 21:31.000] not the processor whatsoever, [21:31.000 --> 21:43.000] so that you can just say to your computer [21:43.000 --> 21:45.000] which is the name, [21:45.000 --> 21:49.000] and the resolution is provided, [21:49.000 --> 21:53.000] and the definition of all the networking configuration [21:53.000 --> 22:00.000] is provided getting replies from the DNS server. [22:00.000 --> 22:05.000] Okay, I have to stop. [22:05.000 --> 22:12.000] I have a lot of more examples to give you. [22:12.000 --> 22:16.000] Questions? [22:16.000 --> 22:21.000] You can just repeat it. [22:21.000 --> 22:25.000] What is the overhead of using a network stack in every thread, [22:25.000 --> 22:28.000] especially if you're using the one-time IPs for each connection? [22:28.000 --> 22:32.000] What is the overhead that you get within the application [22:32.000 --> 22:36.000] if you have a lot of connections coming in? [22:36.000 --> 22:44.000] For sure on single connections we have some performance drop, [22:44.000 --> 22:50.000] but the point is that the overall bandwidth [22:50.000 --> 22:55.000] by all the applications you have on your system [22:55.000 --> 22:58.000] can use the entire bandwidth, [22:58.000 --> 23:05.000] so you have the experience that you spread democratically [23:05.000 --> 23:13.000] the bandwidth among your processes. [23:13.000 --> 23:31.000] Questions? [23:31.000 --> 23:33.000] Sorry, I can't tell you. [23:33.000 --> 23:39.000] Is latency a factor like bandwidth? [23:39.000 --> 23:51.000] Actually, the point is that behind the user-level stack [23:51.000 --> 23:54.000] there is a virtual network, [23:54.000 --> 23:57.000] which is a virtual-disputed internet, [23:57.000 --> 24:01.000] that using support like VxVD, [24:01.000 --> 24:05.000] which is like a VxLan without VTAP, [24:05.000 --> 24:11.000] so each process is part of the distributed stages. [24:11.000 --> 24:18.000] Latency are quite good because you have a direct UDP connection, [24:18.000 --> 24:23.000] a unique connection from end-to-end from a process [24:23.000 --> 24:26.000] in one machine to the process to the other machine [24:26.000 --> 24:50.000] so there is a direct UDP one-to-one. [24:50.000 --> 24:56.000] My idea is to have a new concept of computing elements, [24:56.000 --> 25:00.000] so instead of having your computer with the process, [25:00.000 --> 25:05.000] you have locally a network of a cluster of computers [25:05.000 --> 25:11.000] with all the processes which are of different networks. [25:11.000 --> 25:13.000] So you have the real networks, [25:13.000 --> 25:16.000] which is just the basic framework, [25:16.000 --> 25:23.000] and you extract this in a number of virtual networks [25:23.000 --> 25:29.000] that connect the processes running in which fields cannot be like. [25:29.000 --> 25:31.000] That's all the time we have. [25:31.000 --> 25:47.000] Thank you, Denzo.