 First of all, let's start with the documentation. As usual, please follow the link in this slide to get full access to all of the documentation both by Microsoft, as usual docs.microsoft.com slash Azure slash Netflix Duo and so on, and also the documentation by ST in terms of Wiki. So Wiki.ST.com slash Netflix Duo, et cetera. On the XQ Badura toss that we are using since this early morning, inside this package, we find also the source code and the example for the Netflix Duo. So not only the operating system, the file X, the USB X, but also the example for the network Duo for the TCPIP. Let's go inside more detailed. The Netflix Duo is IPv6 already certified. This is because of the naming Duo, IPv6 plus IPv4. It's supporting a lot of LFC, both for IPv4 and IPv6. All of them are certified by XIA, by EXANVL, so Automated Network Validation Library. This is for the compliance to all of the RFC listed here. The source code is provided again in C code. The list of the API is BSD compatible. So for the ones that are already familiar with the Unix system, the Linux system, you have again also here the API in BSD format. So you have the socket usage and bind list and accept. So the usual API. Chart about the security. When we talk about Internet of Things, it's always a matter of security. The security is a big part inside this library. You have security across all of the TCPIP layers. From the IP with the IPsec going up to the TCP and UDP with the TLS and the DTLS, and also the legacy version of the TLS 1.0 that is the SSL 3.0. TLS is supported up to version 1.3, the latest release in 2018. This is a plus in terms of security, respect to the 1.2, the current standard of the FACTO. It decreases the number of message exchanged during the end shake from 4 to 2. This means that using the TLS 1.3, it's decreasing the potential vulnerabilities. Let's say, if you half the number of message exchanged during a connection, you are also helping the number of potential vulnerabilities, the exposure to the potential vulnerabilities. Obviously, with the new standard, TLS 1.3, more security features are added, more elective curve, and not only because it also stops all the protocol, like the CBC, like the RC4, like the Shawan, like the MD5, and so on. All of the protocol that are no more considered valid and strong to the potential attacks. I want to highlight also the DRFC 52.8, so the support of the certificate in PGAI format, both in an ashy way and in a binary way. Going on about the certification, like we did in the previous session about the FileX, also here you will have a lot of certification by Tuve and UL for the electronic device, for the medical device, for the automotive industry, for the railway industry, and also for sure about the UL, about the home appliances, so all of the electricity, gas, and so on devices. All of them used at home. Not only designed for security, but also designed for small sites because it's based on Peconet architecture, so written for embedded system. It's scalable, it's written in C code, it's highly modular because its functionality is included in a separated C file, and it means that it's more easy to update and employing hardware resources of the MCU. It's highly scalable because a linker is absolutely not adding any feature that is not required by you, but your code. Like FileX and USB-CX, also the Netflix Duo is supporting the Trey6, so you can perform some post-mortem analysis to try to understand what is succeeding or what is succeeding when you stop the debugger. Being part of the Microsoft Suite, it supports also the FileX. Since you, for example, can embed some server inside your device, some web server, for example, you need a file system to search for the required resource, for the requested resource, and give back to the client that it's asking. So you need a file system, and the FileX is fully supported. In the demo we will see later, FileX is not included to offer, to give you a more easy to understand, a more smaller demo. We will use a file system that is directly written in flash. So the HTML file, the resource file, the JPEG, PNG, and so on, are converted into binary format, so into another file, and written inside the flash of the microcontroller. But this is not meaning that the Netflix Duo is not supporting FileX. This is only a way to simplify the demo. Chart about the list of the protocol supported. This slide is not fully including all of the protocol that are offered by Netflix Duo TCP IP stack. For the full list, I kindly ask you to follow the link in the top right corner to have a full list of all of the supported protocol. Let's quickly scroll the table. For example, let's start from the beginning, out of P. Out of P is a way to automatically assign an IP address to the device if the device is not able to get an IP address from the network. For example, because the DHCP server is not replying. The device, the stack is able to automatically assign itself an IP address in the range of the 169.254.0.0 with 16-bin network. And this IP address is only used as a recovery mechanism. Because when the DHCP server will come back to life, let's say the out of P will stop and the real IP address will be collected by the server and use it. DHCP server client is supported. You can have also a column about the sides needed, both in terms of flash usage and RAM usage here. ICMP and EGMP are supported. So control message protocol versus group message protocol. So unicast versus multicast and so reachability, I mean the ping versus the synchronization. It's supporting RARP and RARP. It means IP to Mac and Mac to IP. So the physical, the conversion between the physical address and the IP address. NAT network address is a transition is supported. This allow your device, for example, to modify the IP address if you want to implement a kind of a router, let's say. SNTP is supported. SNTP is a simplified version of the NTP being based on the UDP. It's used, for example, by Philex. We saw before, for example, to set up the date when a file is going to be created. So you need a timing and the SNTP is here to solve this question. In the right part of this table, there are protocol, let's say, at an higher level. So at level four of the TCP IP stack, so above the TCP and or the UDP. For example, the SNMP is the network management protocol. Simplified, simply simple network management protocol. It's built on top of UDP and it allows to simplify the configuration, the management of your device inside the network. This is the purpose of the SNMP. There is also the PPP that is not listed here, but the PPP is fully support and it is a protocol layer one, let's say, of the TCP IP stack. So behind the TCP and it can be used to set up a point-to-point connection between two devices, between two nodes. The rest of the protocol on the right side are all of them based on TCP and also being based on the TCP, they are also based on TLS. HTTP 1.0 up to 1.1 and the secure version, meaning HTTPS, and supporting all of the method. We will see later in the demo one of the method used by the web server. Email protocols are supported, both for sending, so the SNTP, and for receiving the POP3 as a client, obviously. Both the transfer protocol about the file are available. So the full version, let's say, based on the TCP and the trivial version based on the UDP, the TFTP. Again, both of the methods are implemented. So you can use both the GET and the PUT. So if you want to download a file, you use the GET. If you want to upload a file, you can invoke the PUT. MQTT is a nice protocol. I think you are familiar also with the MQTT and there is a demo also for the H7 family, also about the MQTT. You can implement this demo inside your nuclear platform, nuclear board, you can, for example, attach on top of the nuclear also, annex nuclear with some sensor and try to build a packet, register to contact a broker, for example, Mosquito, create a topic, subscribe to that topic and then use also other device to subscribe to the same topic and receive the messages sent by your nuclear. This is a mechanism that is quite similar to the WhatsApp groups you have on your smartphone. When you enter a group, you are subscribing to a topic MQTT, let's say. When you receive a message, you are receiving a message because someone else made a post to that topic, to that chat group. Next slide, the sign-in for speed. It means that we are able using this library to reach an almost wire throughput. What does it mean? Since this library is supporting an implementing zero-copy API, it means that the buffer are not replicated, are not copied from a layer to another one. So when a layer receive a message, it's not needed to create another buffer, copy the PDU and pass this message, this smaller buffer to the upper layer. Only a buffer is needed, all of the layer are used in the same buffer, so zero-copy is implemented and this way you are able to reach very, very, very high throughput. This is because we write almost wide throughput. The sign-in for speed also because it's supported the hardware acceleration by hardware, obviously by STM32, about the CRC, so the C-Click Redunda check. Multiple interfaces are supporting. It's possible, for example, to have one public address for the usual operation and another private address for operation like debugging reports, statistic and so on. So multiple IP address and also more security because you are not fully opening all of the feature to the rest of the world. About multiple interface, also multi-homing is possible, is implemented, is supported. This way it's possible to, let's say, freeze your application, so build your application, build your source code, fine-tune your application and in the end, decide which physical channel you can use, you want to use. Also, static routing is supported. Even if using static router is not so useful because it's not, let's say, it's not adaptive, it's not adaptive routing. So if it's not fault tolerant, so if a device in the middle of the network crashes, all of the remaining parts of the network is lost and is no more reachable, let's say. One final slide before moving to the demo, to the show. This slide show you the flow, let's say, from the initialization to the application up and running. There is a fundamental step in the middle and if you are familiar with the Linux environment, you know that when you create a network, the last step is to get an IP address. And in this case, your application register a callback and when the callback fire, it means that your application is able to go on and turn on the remaining part of the system. For example, about the web server. Before the web server is turned on, you need an IP address, basically. And the IP address cannot be self-generated. You need a guy in the network external to the nuclear shield, let's say, external to your device that give you an address. This way, your application, your nuclear is waiting for the DHP server to give you the address. When the address is received, the callback fires and this way your application can go on and opening the web server, opening the port 80, and the web server socket will stay open to accept the incoming connection. So you will have a usual thread, for example, but you will have also two timers. This morning, Manuel discussed, showed you some component, some extra component inside the Azure AirTos library. Those are, for example, the software timers. This task, this library needs two more timer other than the thread itself. One slow timer and one fast timer. Why the fast timer? Okay, the fast timer is the engine, let's say, of the library, so not a big deal. The slow timer is usually fundamental for, for example, for the reliable connection, for the TCP-IP connection. If you have a reliable connection, your system, your library must be aware that something wrong can happen or must be aware if something wrong happened. This way, he needs to be advised by the timer that is taking care about the timeout, think about the TCP. And if something bad happened, say to the application that something bad happened and the application or the library itself is able to, for example, close the TCP socket, the reliable socket. Even if the acknowledge are lost or even if on the other side something bad happened.