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