 All right. Let's get started. Well, thank you for sticking around. If I were not giving a speech right now, probably I would have wondered of myself and grab some lunch. So thank you for that. So today we're going to talk about our socket. So first introducing myself. My name is Andy Shea. I'm from Alibaba Cloud. We have an office in Northern California. It's an engineering office. So I'm an engineer working there. Also I'm the developer advocate for certain open source projects. About 10 months ago, we were introduced to this fantastic technology called our socket. And over the course, I learned that it's great for connecting devices. It's great for connecting applications, microservices, anything that doesn't involve a human being. It's great for. So today I'm going to share that technology with you. And hopefully you can spread the words and I can get some feedback. Now let's first talk about the definition of our socket. Now there's a long definition and there's some features. We're going to talk about that later. But for now, let's simply remember that it is an application protocol. So what it means is it's not dealing with signals like Wi-Fi signals. It's not doing NFC and other things. It's an application level protocol. And it gives developers the freedom that they don't have to worry about signals. They don't have to worry about IPs and ports. So they're addressing services devices. So that's what our socket is. But then I was thinking how do I introduce a protocol in certain minutes. It's measuring possible. So I was thinking of doing a demo. But for some reason, this demo cannot be set up here. Let's check. Oh, it can. So I tried this demo upstairs in my room. It works. So let's hope that this is going to work at here as well. So here's a simple demo setup. I have a Raspberry Pi device that has a camera attached to that. And it's rendering a service called Camera. It's taking a snapshot. And it's going to send the picture over. So the Raspberry Pi is connected to an R socket broker. It's a broker. That broker sits in public cloud, our own Alibaba cloud. And they're talking in R socket. I have another device conveniently in my laptop that's going to consume the service. It's also connected to the broker and also going to the cloud. And it's going to request that picture. So let's do that. Hopefully that works. How long does it take? OK. Now let's see. Can we see? No. So I'm wondering how do I do this? Let me exit this first. And we are able to see a blurred picture with no good lighting. But you get the idea, right? You get the idea. That's how it works. OK. Now seeing this very unimpressive and boring demo, you probably are wondering, what are we doing here? Why are we doing this? Because there are multiple ways to achieve the same thing. So bear with me. This demo, as boring as it is, it lays some foundations for the talking points later. Now first thing we need to clarify is why do we need a broker? I have my device here. I have my laptop there. And our socket can easily make that point-to-point connection work. So why bother going all the way around? Well, because we are thinking of the real use case, the real-world use case, where it's not just two devices. So it's multiple devices talking to each other. And we need to figure out a way to connect them. And putting a broker in between simplifies that. And that's a proven topology. Many other technologies use the same deployment model. But I need to clarify, though, that our socket is not a message bus. It's not the message queue. It's not doing the pub sub-style trafficking. So for a broker, for an our socket broker, it has to solve problems like service registry, service discovery, and load balancing. And of course load balancing is not within the boundary of the protocol itself. We're not going to talk about it, but still we need to discover how we can do discovery and registry. So any suggestions on how we do that, like any good packages that we normally use for service registry and discovery? Anyone heard of any good packages? There are a couple of them, right? Yes, service mesh. Thank you. Service mesh is a technology that helps you to connect the services similar to what we're doing here. But in particular, when you are talking about registry and discovery, you probably need a third-party tool to help you. There are like console and others, very famous ones. But guess what? Our socket doesn't need any of those. Our socket does not need a third-party tool. So here's my code in the broker. This is the part where it returns to a connection. So it's going to return a handler, and I've taken out all the other logics. But look at the two things. It registers and subscribes to two events, on success and on terminate. So when you are connecting, it's successful. There's an event getting triggered, and then you can do things. You can do things. And what do you do? You put the metadata of the service somewhere as a registry, right? And on terminating, what do you do? The same thing, you take out that metadata and say this service is no longer available. So by the simple piece of code, you can achieve a complicated third-party tool that can do. And how is that possible? How is that enabled by our socket? So our socket has this feature. It's called connection-oriented. So what does it mean? So basically our socket, when you connect to it, it's going to establish a long connection. It's going to establish a long connection, and it's going to establish sessions. And then there's a thing called set of frame. We're going to talk about that later. But set of frame is first, when you're first connecting to the broker, you're going to give out the metadata of what your device is about. You're going to give out the service name or whatever that's agreed upon. And your broker can then build a registry on top of it, and then you can later serve it, right? And also, when you have multiple instances of the same service or device, you can build algorithms of load balancing. You can build fancy algorithms of load balancing with it. And of course, we have this event that's going to be subscribed by the broker or by the connection. So it knows when the connection is available, when it's not. So we don't need all the other tools. And that's a nice part of our socket. It simplifies a lot of things. So the benefit of connection oriented is that obviously we just talk about no third-party registry. Also, we don't need third-party house check because we already know when the connection is up or down, right? And a good part, and I think it's really useful for IoT devices, is it has session resumption. Session resumption. What that means is it's beyond connection resumption. So let's say my device got disconnected. When you plug it back, it's going to resume the connection. That's normal. But let's say this device was transmitting 10 frames to my laptop, and on number five it stopped, right? In the middle of number five it stopped. So what resumption gives that is going to resume transmitting from frame five because it was not complete. So that's what session resumption does. And it's really powerful and useful, especially for IoT devices, but for other services as well. So this is one feature that I think that's interesting coming out of this demo. Another feature we're going to talk about is how we connect to the broker, okay? So this is a code on both of the devices, on both the Raspberry Pi and my laptop. It connects to the public IP of the broker. Now, the second line is the setup payload, setup frame we just talked about. It contains the metadata of your device and your service, right? So it's just one time. And the third line, that's the interesting part. So it's going to be connecting to the broker. Now, here's the thing. This Raspberry Pi is offering a service. Now normally when you are rendering a service, how do you do that? You open a port and you listen to it, right? You open a port and you listen to it. Now, in this case, we're not doing that. We connect to the broker. And then when there is, even without a broker, let's say these two are connected together, the Mac can just request to the Raspberry Pi as for that service, okay? So that's a powerful feature of our socket. Because let's think about it for a minute. When do we have the distinction between a client and a server? Meaning that communication has to be initiated from the client, right? TCP does not have that distinction. TCP doesn't have it, right? You have to open a port, yes, but the one that opens the port can initiate the communication, right? Who does that? Client and server. HTTP does, right? HTTP is designed for human beings sitting behind the browser and requesting service from a server. So it is designed to protect the consumers that the server doesn't push unnecessary stuff to the browser. That's why it has this distinction. But that model of communication does not apply to applications communication. It doesn't apply to IoT communications, right? Why do we have to, in the last talk, I don't know if you guys were here, but in the last talk, the one before me, the professor was talking about how every time you restart, you need to figure out the IP address. That's painful because you need to figure out the IP address and you need to give out a port so that you can listen to that port and establish a service, right? So this feature what we're talking about is called bidirectional communication. So bidirectional communication gives us certain benefits. Of course, for IoT devices, it's huge that security. When you listen to a port, there will be attacks, right? When you don't listen to a port, you don't have that attack. And IP management, right? It's hard for IoT devices, it's even hard for edge devices. I was working on something a couple of weeks ago that we need to come up with a list of IP address. So each time that the edge device, the server starts, it's going to have the same static IP address, which is against designs of many things. But above all, it's great for connection management. So you don't have to worry about upstream connection, downstream connection. It's one connection. So that's a power of our socket. So we've gone through two major features of our socket. Connection oriented and bidirectional communications. So what else is available, right? So that's the four points on the first slide. So let's talk about the features that's available for our socket. Our socket is a binary protocol. It's not a tech space protocol, so it's more efficient. And it's message-based protocol. So what that means is it has message information embedded in the same type of payload as your other payload. For example, we just talked about setup frame, right? We're going to talk about all the events, right? How does it check for the liveness? So there's a keep a live frame, and there are other frames. All those commands are in the same format as the others. They all appear as the same frame format. So that's a message-based protocol. And we just talked about bidirectional and connection oriented. So these three things, bidirectional, multiplex, and connection oriented, makes it really powerful. Now, of course, it's hard for me to demo the multiplex. I cannot think of a simple demo that can do that, but all these three make that really powerful. And of course, there's another point of the four interaction models that we have not talked about. And here they are. So the founders or the creators of this protocol, they were thinking of the patterns of communications between applications, between IoT devices, and they came up with different patterns for different models. One is our familiar request response, right? We all know what it is. The second one is fire and forget. Fire and forget is when you send something over, you don't care about the returns outs, right? For example, if you're writing something to the logs, you don't really care if it's received or not. So that's one use case. And also, I think for people who are familiar with MKTT, there's also that feature. And the third part is request stream. Request stream is when you send a request, you get a stream of responses, not just one, you have plenty. And the last one is a channel that's bi-directional streams. So the thing to remember is, even though there are four different types of interactions, you only need one connection. It's that long connection you established at the beginning that's going to serve all of them. You can have them together. You can have one by one. It doesn't matter. But that connection is going to stay there. And if it is disconnected, it's going to resume. So one connection multiplexed. So that's how multiplex works. So you have different types of streams. It's going to be using the same socket. So we've talked about the major features of our socket. And now let's drill down a little bit more. And that is what's the design principles behind it? Other than making it convenient and adaptive to all the application communication models, what's the design principles behind it? And that's a tough topic, I would say. But let's start with the name. We know what socket is. What does R stand for? R stands for reactive streams. I'm not sure if we all have heard of it, but it's a programming model that's been around for some time. Now, I'm not going to go too deep into that because that's going to stir a lot of debates and whatnot. But the two major design principles, and I think it's the design principles for all the distributed environment or architecture, is it focuses on asynchronous and non-blocking I.O. Asynchronous and non-blocking I.O. I mean, it's not hard to figure that out because you have things that you don't have control over. So the best way to deal with it and make sure you're resilient and high performance is to get around it. So you kick the one that's blocked out and you make sure the one that's not blocked can get in. So that's how you do it. Now, there are different ways to implement asynchronous and non-blocking I.O. It's not just reactive. That's the only one. There are different ways to do it. But what makes reactive streams stand out is the concept called back pressure. So what is back pressure? Let's go back to asynchronous and non-blocking for a minute. How do you implement that? How do you implement asynchronous and non-blocking I.O.? You need to query your operating system to know which processes are blocked, which ones are ready. You need to do that. Now, the problem is, what about the devices that's not in your control? What about the other devices, other services that you cannot query their operating system? You cannot do that. You cannot subscribe to an event and say, hey, the operating system on the pie tells me when this thread is ready. You cannot do that. So you need the measurement to know when it's ready. So that's what back pressure is. Back pressure is the consumer telling the producer, I am ready. Give me a couple of frames. That's what it does. Nothing else. It's a very simple, yet it is very genius design because what are the other alternatives? Either you do long pooling. Are you ready? Are you ready? Are you ready? Think about that. Effective? No. Or you do the other way. The consumer is saying, I'm busy. I'm busy. I'm busy. Does it work? Of course not. Because when you're busy, probably you're already blocked. How do you send out that signal? So this is a genius way of design. And I love this picture, these two pictures of how it describes back pressure. So when you don't have back pressure, when you have a surge of traffic, that's what's going to happen to the man. And then when you have back pressure, even though she's drinking from a bottle, imagine that's a hose and she's saying give me like two tablespoons. That's what it does. That's what back pressure does. Now, reactive streams has been around for a while. This concept has been around. So what does our circuit do to make a difference? So it turns out that back pressure, when it's originally developed, it's not enforced on network. So what our circuit guarantees is end to end back pressure. So what does that mean? Let's say you have more than two devices, like five devices. One of them is slow. You need to inform the other four. Whether they are in parallel or they are in the chain, you need to let the others know. If you are relying on TCP to deliver that back pressure, it's hop to hop. It's hop to hop. TCP has a sliding window, but it's at transport layer. It doesn't know your application status. It cannot query backwards. So it can only do hop to hop. And our socket can do it through message-based protocol. That information, that back pressure information is encrypted in the request frame, and it goes around the whole system. So it enables end-to-end flow control or back pressure. So that is, and that's how much I'm going to talk about reactive in general, because I know it's a broad topic. But that's the principle behind our socket, is to ensure your asynchronous and non-blocking IO goes all over the system end-to-end. All right. So next topic. And that's a little bit more controversial, is comparisons with other technologies. And the first one is what I always get asked, the difference from GRPC, because GRPC is very popular as well. So what GRPC has, it has two parts. It has an RPC part. It has a protocol part, right? What our socket is, it is a protocol. So it is not an RPC layer. Actually it works with Protobuf. So if you have generated your protocol files, cool, you can just port it over. You don't have to regenerate them. And it supports other encoding mechanisms as well. So now let's talk about our socket versus HTTP, which is a little bit controversial. So over the years we've seen HTTP2 and now there's HTTP3, and there's a lot of great features in vision. There's a lot of great improvements that has been done. We've seen server push. We've seen multiplex. Now HTTP2 is also binary protocol. So we've seen a lot of these things going on. And HTTP3 is more ambitious. And you can see that they are doing something that our socket has already implemented. So that's a great thing. And we like it because it not only validates our socket's idea, but it also means that the communication model has shifted from the original human browser to web server to application communications. So that's a great thing. But here's the thing. HTTP is a popular protocol. It has to make everyone happy. It has to make everyone happy, which means it's really hard to become truly reactive. Now let's take one example. Let's say there's a flash sale online, and you want to buy something, and it's only one minute. So you put this thing on the shopping cart. You wait for the time to come. And if this whole system was implemented in our socket, what's going to happen? So you're going to wait because that checkout button will not appear until the web server gives it a green light. So that's not the user experience you want. That's not the user experience the sellers will want. What they want is you keep clicking, keep trying, and only like 10% of them get the flash sale deal. That's what they want. So in other words, our socket kills the fund. It kills all the enthusiasm when there's human involved. And HTTP, though, has to support that. So HTTP cannot be truly reactive. It cannot truly embrace that high performance asynchronous non-blocking I.O. So imagine that user experience what it does to the system load. It creates a lot of junk connections. It's disconnected. It's a mess. But that's where it is right now. So our socket is not trying to please everyone. It's only designed for certain use cases, and we try to make those use cases work better. HTTP is well established. It has to support everyone. So that's the difference. Now, another comparison we always have to do is against message queues, especially in other talks, people always ask for Kafka, because I think I was mentioning the brokerage deployment model, and also because I mentioned there's a message-based protocol. But let's take a look at what happens when you have a surge of traffic and there's an imbalance between the consumer and producer. So the left would be your MQTT that's anticipated, expected. The middle one would be our socket. So that's what we have explained. So the right one is a little bit interesting. This is Kafka. So what Kafka does is it's going to cache all the data, and then it's going to still use the same rate, the rate that the consumer can accept to send the traffic over. So think about that. I mean, I work for a cloud vendor, and I love customers to buy storage and memory-based cache. I love that. This solution wouldn't scale. Eventually, you're going to run out of your storage or memory or whatever. So right now, if you use Kafka to connect devices, there's already limitations. Because of the partition it does, it cannot accept too many topics. So there's a limitation on the topics, and then there's a limitation on the device numbers. So that's where we are today in terms of comparison with MQTT and Kafka. But by no means are we diminishing their existence or trying to make them look bad. In fact, we're working on a couple of projects. One is adapters or gateways to MQTT. One is the gateways to Kafka. So as long as our devices can be reactive, we can have a better performance, we can have a better architecture, and it's going to benefit everyone. So that's pretty much the content that I would like to share. In terms of our socket itself, it's an open-source project. It starts from a spec. So the founders actually saw this through. They were thinking of different use cases for communication models, and they wrote it down. So there's an R-Socket protocol spec, and there's a routing spec which is for broker. And you can check out the website. Welcome to join us as community contributors. Right now it has different SDKs. There's Java, there's C++, there's JavaScript, .NET, and there's a GoLan. And we're working on Rust. So there are different languages that support it. And the exciting thing is we're becoming a member of Linux Foundation. We're going to have sub-foundation under Linux Foundation, and that announcement would be next Tuesday also. So you might get that notification if you subscribe to that. And yeah, during the conference we might have some release, press releases I'm not sure yet, but hopefully that's going to be enough information to get you guys the motivation to try it out. All right. So that's what I have for today. Any questions, comments, feedbacks? Yes, please go ahead. Exactly. Fantastic. Thank you. So you're thinking ahead. So the question was how do you scale the brokers so it can connect multiple thousands or millions of devices? So there are a couple of things. One is remember that one device has only one connection, and the connection is pretty small. So we've tried very conservatively one box can easily support more than 10,000 devices. So that's a cool fact. Another thing is when you have a cluster of brokers, you need to have a mechanism to synchronize them. And that's something that has to be done either at commercial level or you have to somewhat customize it. Right now we have a basic broker that's going to be open source. There are commercial grade clusters of brokers that's available down by a startup. So that actually you can basically have a cluster of a couple hundred, if not more. So what it does is it opens another port to each other, and then they are basically exchanging information using UDP, but it's still on our socket. So they're exchanging information in the same asynchronous and non-blocking way so that it doesn't block too much of their performances. So they have, I think they have benchmarked a couple of hundred brokers in the cluster, and that's fine. Other questions? Yes? I'm not sure about how small the devices you're talking about, but so the question is, does it only run on Linux-enabled devices or it can be smaller? So it really depends on your device. So right now we have SDKs returning those languages. So your device has somehow to be able to compile and run those code. You have to be able to run those code. That's generated. The binary is that's generated. You can compile it somewhere else and then load it. I don't know if that's going to make things easier, but as a protocol itself, our socket is not just for IoTs. Like I said, that's good for microservices. It's good for any distributed environment. It's good for devices as well. But it's not limited to devices. It's as long as it can be accepted on the device. So before coming here, I was trying to set up the demo on one of those surveillance cameras so that we can have a stream of videos. But then I realized that I cannot program on those things, and it's already pre-programmed. So if the device manufacturer supports this, then we definitely can have a better use case on those devices. Any other questions? All righty. Thank you very much. Thank you.