 Hello everyone. My name is Zuo Zhenghu and I'm from Alibaba Clown. I'm glad to introduce the Dragonfly V2 to everyone today. We believe that V2 architecture will bring a breakthrough in the domain of the cloud native file and image distribution. First, let's take a look at the current situation of Dragonfly V1. At present, the number of stars of Dragonfly V1 has reached more than 5,500, and the number of adopters has also exceeded 110 involving various industries such as telecommunication, finance, cloud computing, log life service, and so on. They are termed maintenance in the project, which are from Alibaba Clown and the group Baridens, Ebay, and Meitu. At present, there are 77 contributors. Here we warmly welcome more people to join the Dragonfly project. Our discussion group includes DingTalk and Gitter. So, what probability do you ask to initiate the Dragonfly V2 project? There are many flowing reasons. First, Dragonfly V1 had some defectors in the architectural design. It faced to meet the growing needs of the file and image distribution business, which gradually exposed its deficiency in stability, efficiency, and security. Second, currently, it can only support HTTP protocol and lacks the adoption of four other types of storage such as HDFS, storage service formal, various cloud and windows, maybe YAM, and so on. Thus, it greatly restricts coverage, seniors, and further kindles, proportion, and values diminishing in companions and communities. Third, currently, it only supports the active pull model and lacks the active push as well as secondization skills, which are the basic conditions to satisfy for our product positioning. Fourth, Dragonfly V1 lacks the productive, no task management and control, data dashboard, multi-tenancy, permission, control, and so on. Fifth, inconsistent internal and external versions, high maintenance cost, and difficulties to synchronize new features and problem fix with a short time. Completed with Dragonfly V1, V2 system has brought some innovation in many aspects. In terms of architecture, firstly, the sub-systems are decoupled from each other and support on-demand deployment, which makes the architecture more flexible. Second, it supports the third-part tools to integrate Dragonfly ability natively, such as various cloud storage download tools. Third, compared with the V1 architecture, V2 supports better horizontal scalability. With the expansion of CDN node, the pressure-only mode source demands basically unchanged force. It provides higher availability granted by encapsulating RPC framework. In the aspect of scheduling strategy, first, task dispatch is based on peer granularity to improve the throughput of a single scheduling node. Second, through real-time analysis of the result of the client, so as to dynamically adjust the peer-to-peer network structure to achieve scheduling optimization. Thirdly, other scheduling strategies are supported by plug-in way, such as intelligent scheduling based on machine learning algorithm on the client side. Through yellow copy, streaming downloading and current offloading technology, the IO efficiency of the client is greatly improved. In terms of productivity, first, support more distribution models such as pushing, synchronization, remote copy and so on. Second, it supports account, authority, talent. Third, it supports dynamic configuration management to facilitate real-time control of subsystems. Fourth, it supports the dashboard and the trends and so on. Just explained why we decided to initiate Dragonfly V2 project and its innovation. So, how do we design it? This is the module structure of Dragonfly V2, which mainly includes manager, scheduler, CDN system, client SDK and only RPC framework. The manager is the central controller of whole system, which in provider's dashboard, use a task management and configuration management and expose less for API. Scheduler is mainly responsible for scheduling peer and acting as a metadata trainer. CDN is mainly responsible for making seeder and catching files. Client is mainly responsible for uploading and downloading files, and is integrated by other set part tours through SDK. Finally, each subsystem communicates through RPC framework. Next, I will introduce the way to architecture from the perspective of interaction between subsystems. Let's first take a look at the solution of Dragonfly V1. As shown in the figure, the whole architecture into layers include super node, providing scheduling and CDN capabilities, and def guide client deployed on each machine. In the Dragonfly V2 architecture on the right, it is obvious that there is a big difference between V1 and V2. First, scheduler and CDN are decoupled and interact with each other through the RPC interface, and the CDN is optionally deployed. The client is in client and server mode, which is divided into def guide and def demand, which are executed through different subcommands. The def demand provider service, which is responsible for downloading and uploading five blocks and providing proxy capabilities. Def guide and SDK request def demand to generate a down task by calling RPC interface. Finally, the manager is mainly responsible for configuration management, keeping alive and controlling the subsystems, and managing it also optionally. I have just introduced the overall or technical architecture of Dragonfly V2. Now, let's take a look at the core data model of the Dragonfly V2. As shown in the figure, each PR host represents a machine instance on which multiple file downloaded jobs can be triggered simultaneously, and each downloaded job corresponds to a PR task. Each PR task completes a whole file download by executing multiple pieces task, and the pieces task represents a five block downloading task. Finally, multiple PR tasks form a large P2P task, and five blocks will be transmitted among PRs in the P2P task. Through the previous introduction, I believe everybody has a general understanding of Dragonfly V2. Next, Jim will give everybody a more specific introduction to the client. Hello, ALM. I'm Jim Ma, come from N-group. I will share in the next slide. Let's talk about the evolution of client. The usage of def guide is similar with def guide. It can download files with P2P, P2P network. There are some significant changes in def guide V2. First change, download process. In V2, we split Supernode to Schedule and CDN, and add a manager for multiple classes configuration supports. The main process, Zhengxi has talked about it. We just skip it here. Second change, integration protocol. In V1, def guide calls Supernode with HTTP protocol. Now in V2, all actions are done by GRBC building with HTTP support, HTTP to support security, and easy integration with other programming language and tools. So the change embedded some words for def demo. The def demo in V1 is a process to accept HTTP process request, and it will transfer the request to the def guide commander. Due to one request, one def guide, def demo cannot process thousands of requests. Now in V2, def guide come with def demo. When using def guide as a proxy demo, all requests will be processed in one def guide demo and support thousands of requests. That's very great. Not only change protocol and module code, but also reflect toward high performance and the more future for def guide. Let's discuss this enhancement. First, bidirection, stream GRBC with other components. Second, uploading file with send file, and the supply support benefit from Golang transfer data from OS5 to TCP connection is done by Golang standard library. It's without memory copy from kernel to user space. Third, download file with supply support. Unfortunately, transfer data from TCP connection to OS5 is not coming with any benefit from Golang standard library. We have implemented TCP connection right to function for optimaize. OS5 with supply support for Golang with these changes, when transfer data will not be copied from kernel socket cache to user space and from user space to kernel page cache. Instead, data will just be copied from socket cache to kernel page cache. When rebuilt, def guide with our optimized Golang, we get 10% at least CPU reduce. There are memory copy from kernel to user space. Look at here. Next, about file digest. Normally, we calculate the file digest using standard library in Golang. Kernel must copy all data from user space to all data to user space, but Dragonfly data are immutable in most cases and always hit the page cache. Using AFLG with kernel crap or API, we can avoid copying data from kernel to user space. Our code can be found in GitHub from here. Here is the performance. The same real time, but with zero copy to the user space. It's very nice. For performance, TOS offloading is an option for def guide proxy. When able, TOS offloading, the client likes Docker, Demo, CIL, Demo, container D, Demo are communicating with def guide Demo using pan HTTP instead HTTPS. TOS terminating is done when CDN downloads from source or def guide Demo downloads from source. Our intersection can be found in this figure here and here. For tuning performance, def guide is out of box with telemetry. In V2, we will spot open telemetry collector, YAKO tracing, ProMatches, and Grafna. Here is a screenshot for tracing from YAKO. These are about client changes. Let's take a look at our ecosystem. The Dragonfly container image service. We call it NIDUS. It is a user space fire system building on top of the container image format. The duty of NIDUS is to reduce the cost of image pulling, accelerate the long speed of containers, enable the load container on demand, as well as ensure the integrated, integrated of the image container. In the largest scale data center like End Group and Alibaba Group, the cluster case of NIDUS is thousands of containers are launched very second and thousands of images are hosted by NIDUS in the same time. Dragonfly helps NIDUS to do P2P container delivery to solve network bandwidth bottleneck for image loading and reduce reading latency and protect image registry to avoid huge traffic. This figure describes the process NIDUS use Dragonfly to deliver image container instead of make a request directly to image registry. NIDUS just proxy all requests using Dragonfly demo. So that a significant portion of requests are cashed by Dragonfly. It helps to reduce reading request to image registry and reduce traffic to the image registry. Dragonfly has integrated with NIDUS and Hubble. For example, Hubble image can be preheated to Dragonfly and so on. We are working together for OSI-V2 drafter discussion. Let's look forward to it together. Here is current status. All source code is available in Github and most components like DFGAD, CDN scheduler is ready and the manager is under developing. Here is our roadmap. In May, we will release our manager and the standard project improves stepability and support ALG speedup. In June, we will release CDN advanced future and integrate NIDUS. In June, we will support SSL and the incorrect transmission and integrate multi-cloud storage. In August, we will release account authority and dashboard tracing supplies. In September, we will release pressure, sinker, remote copy and file upload. In October, we will release multi-tenants and transfer transmission cross-cloud. That's all. If you have any questions, you can join our team group. Thank you.