Guillermo Rauch: socket.io

My name is Guillermo Rauch. I'm the creator of Socket.IO, also co-founder and CTO of a startup called LearnBoost in the education space. So as many of you might be aware of, Socket.IO is a way of doing real-time applications on every browser, also the server now, with a simple API that resembles WebSocket a lot. So, so far we've seen a lot of adoption and many applications deployed to production with it and many projects created with it, and with that we've learned some lessons and we've finally come up with a spec of how other people that might want Socket.IO and the Socket.IO protocol on other servers and other languages might go about creating it. So the goal for the next release of Socket.IO that has been already pushed to GitHub in an alpha state is sort of implementing this spec, implementing this sort of new features that are going to be the foundation of Socket.IO. And so that's what I'm going to talk about today. First of all, I made some architectural changes. The— like I said, the protocol, the Socket.IO protocol, which is what we need essentially to make WebSocket and long polling or other transports converge and maintain sessions for users so that they— we can, for example, buffer messages on the server and the client. We have— we have made some API changes so that it's easier to get up and running. We have a new way of doing tests, which basically is— I created a Node client that I'm going to use to test the Node server and vice versa. So before, each time you would run Socket.IO, you were limited to storing every message and every user and every session ID on one process of one computer. So if that process were to die, or you wanted to use two computers to handle a number, a higher number of messages per second or a higher number of connected users, you basically had to create a message, basically implement a message dispatcher yourself. You would subscribe clients to a Redis, set or PubSub, or you would use RabbitMQ. So today, Socket.IO is going to take care of that for you. And also, another important thing is many people have different needs as far as how much latency they can afford for their applications. So some people might want to just completely ditch the Flash transport because it adds a lot of bloat. They can afford to use long polling as a fallback transport. So I've made the handshake process, and I've made the Socket.IO interfaces more configurable so that you can easily decide what transports you want to use and other options. I'm going to talk a little bit about the new API. So we made it easier to run a Socket.IO server that is not tied to a particular HTTP server. So before, you would have to instantiate it yourself. Now you can simply call io.listen or pass it a port, and you'll have your own standalone Socket.IO server. Before, you would have to pass this huge object of options with nested objects of options. And now we have Express-like configuration. So you can have different settings for development and production, which for a project like Socket.IO is extremely important. Sometimes your clients might be dropping because of network latency, or you're testing a mobile device, so you want to make sure you know why a certain client is dropping. Is it because a heartbeat wasn't received, or is it because the client is too slow for your settings? So you can customize things as the logger, the log level. Guillermo Rauch: So, like I said, up until today you were constricted to one process and one server. We made some changes to make that more flexible. So by default, you'll still— it is going to continue to store everything in memory. The main reason is that not everyone has requirements to set up Socket.IO in a cluster or perform worker process replacements. With tools like Cluster or Multinode. Like I said, it defaults to memory, and one thing that we had to change in order to make these two modes of operating compatible is that every signature that before was just accessing memory now is an async callback. So from your Socket.IO instance, if you needed to access a client list before you would go Socket.IO.clients, and now you're going to go Socket.IO.clients and pass it a function. Something really useful as well is the ability to associate data with a particular client. So when someone connects, we can, for example, set a nickname. And that's going to leverage the same existing storage that you're using for your messages and for your message queues. So if someone connects and you want to sort the nickname they're going to have for the session, you can do that directly from Socket.IO as well. Another thing that is really important is the ability to send messages that can be dropped and should not be buffered. So, for example, if you are creating an application that displays tweets or you're creating an application that you want to show the latest stock prices to the users, you don't want to— and you're retrieving stock prices every second, but you have a client that is only taking messages every 5 seconds or so, you don't want to buffer every single message. You want Socket.IO to drop some of them so that you always receive the latest. So that's what the volatile flag does. And it's really easy to use. So before, you would say socket.io socket.send, and you would send a message to the user. So now by simply prefixing it with volatile, you can make that message forgettable. So if Socket.IO cannot write it to the user, which is important, for example, for long polling, where the client is opening request and response cycles, and we're only able to write data to the user whenever they open that request, but between two requests— sorry, between a request and a response, we cannot write to the user because it's not server push. So those messages would be dropped while the user is temporarily not connected. Ah. Another flag that I'm adding is called JSON. So before Socket.IO was smart enough to detect that you were sending something that was not a string and serialize it into JSON. So the problem is that even strings can be serialized into JSON. So if you want to force 100% JSON encoding, you can also use the JSON flag. And you can combine them. So if you want to send JSON as a volatile message, you just concatenate them. Another really useful thing is acknowledgments. So the way that WebSocket works, you write a message, you never get a callback unless you implement it yourself. So you can send a message that is prefixed by an ID and then have your server respond with that particular ID. So you would get an acknowledgment that your message has been received by the server. So I built the machinery for acknowledgments into the Socket.IO protocol. And implementing it as a developer— as a user of the library is extremely easy. So every time you send a message, if you pass a function as the last parameter, that's going to send— that's going to append an ID to the message that is being sent through the wire, and the client will respond. And it's also symmetrical, so a client can send a message that has a callback associated with it, and the server will respond with an acknowledgment. Another thing that was actually requested many times and it really doesn't add any bloat to the protocol, and that's the main reason that it's been added, is the ability to define your custom events. So you can still use Socket.IO as a on_connect, on_message, and on_disconnect, but certain applications will fit other semantics better. So if you're creating a chat application, you might want user connected, user joined room, user sending private messages. So now you can define these events, and they are sent through Socket.IO protocol in a very lightweight way. So instead of going— sorry, here is not io.onChatMessage, it's socket.onChatMessage. Essentially, you can define custom— the event emitter is overridden for Socket.IO, so you can define your custom events and emit custom events. For events that are user-defined, the parameters that you send are JSON-encoded. That means that you can send objects, you can send strings, dates, or any other encodable entity. So like I said, events have no protocol overhead. They are optional. You can still use Socket.IO as a cross-browser WebSocket if you constrain yourself to the 3 basic events. And again, it's compatible with flags and acknowledgments. So like I said, events always use JSON. But if you want to send a volatile event— so if you're listening on a Twitter stream and you want to send a tweet event, and you might want to drop some of them, you can do that by prefixing the emit with a volatile flag. And something interesting is that— An acknowledgment from an implementation point of view is just the server sending us a packet back that is basically an empty string. But sometimes you might want to acknowledge with actual data. So you might want to— you might want to say emit a nickname event and as part of the result get a response of whether the nickname could be set or not or if it was being used by another user in the case of a chat application. And that's also something that events empower. Essentially, when you— when you emit an event, if the function arity, meaning the number of arguments that are defined in the function that you pass it as a callback for the acknowledgment, is greater than 0— so in this case, I'm setting— emitting a nickname event, and the function expects a response object. So Socket.IO will know that your function, the server side, has to respond with data. So in this case, I'm performing an asynchronous task, which is checking for the availability of that nickname. Uh, and this is really powerful because there's many semantics that do not require acknowledgement and do not require data back from the server. So for example, publishing a message to a stream, but there's many that do, and events give you this functionality now. So finally, moving forward with the project, one thing I would like to see is people creating reusable applications and not just frameworks. So today we have frameworks like deno and Juggernaut, which are awesome. But if we want this to become mainstream and we want to really enable people that are creating Web 2.0 applications to start inserting components of the real-time web, we need to make sure that we can distribute prepackaged applications. And to that end, we need to solve basically one problem, which is preventing collisions. And if you have a particular Socket.IO instance, you need some machinery for two different applications to share that without having to initialize two different ones. If two particular parts of your website depend on WebSocket, that's fine. You have two connections. But if they depend on long polling, depending on the browser and how many resources are being loaded and how many keep-alive sockets are open, you might end up with, like, four different connections just for your two sockets. So the idea is that we want to be able to reuse a particular Socket.IO instance but be able to namespace it. And to that end, I added the ability to, like, sockets subscribe to channels without the user knowing or having to particularly subscribe or understand the pub/sub kind of mechanism. And the way it works is really simple. So by default, the— when you define a socket, it's going to subscribe to the empty namespace. That's the default. Again, you can continue to use Socket.IO with— as basically a WebSocket. It— all the messages go through the same stream. But you can also define a namespace just by prefixing your event listeners with for. So that particular socket for the news endpoint is going to act as a standalone socket. Even though it's going to go through the same TCP connections. Multiplexing is automatic, even on the client side. If on the client side you define the same hostname, the same port, and the same protocol, but you only change the resource part of the URL, then multiplexing will be enabled for you. And packets that signal connection and disconnection of events of these sockets will be sent. Which means you can actually disconnect the chat socket and keep the news socket connected. And that means that every single event or every single message that you send is constrained to that particular namespace. So this also fits really well into how you could make your own applications, even if you're not reusing third-party code. So you might have an event called item or an event called message, but they are actually two different things. In two different namespaces. And as far as we're— what we're working on right now and what's coming for the project, so it's obvious that Express is a mainstream web framework for Node. It's the framework that the community chose. And we need that really easy way to leverage and connect session data. With sockets. So a really common need is like, okay, so someone connected through a socket on a particular page, but I want to retrieve what's his username or what's his email from the database. And to this end, the solution is really simple. By having a token of authentication that Express and Socket.IO can inter-exchange, they can— you can know on what page the user is on what particular route and who the user is. So this is a separate project that's coming for Express users. Another thing that is challenging right now is testing different browsers. So every time you make a change to the client or the server, we need to see if IE6 works. And today— till today, it's been largely a manual process combined with really simple unit testing. And obviously unit testing is not enough considering the many quirks that browsers have. So one thing I'm going to do is set up automatic cloud testing on Selenium so that we're going to be able to— as soon as we push to GitHub, we're going to be able to test on all the browsers we want to support. Forward. There's been also many problems related to the Flash fallback that range from sometimes increasing the latency to really high memory consumption to slowness when HTTPS and SSL are used, and also the fact that Socket.IO without Flash is around 8 kilobytes, and with Flash is like, I don't know, like 200 kilobytes. And that's a problem. So we're going to be working on our own Flash fallback. And we're probably not going to be supporting SSL with it, because that's what adds the most bloat to the Flash movie, is the fact that the SSL crypto libraries are not built in into ActionScript. There's also an upcoming WebSocket spec that browsers will be supporting soon, including Firefox 4. And as soon as a major stable browser supports it, we want to support it. And so that's it. You can check out the repo for the latest code. And if you have any questions— So you're asking if it should be connect.io or— so yeah, that's a great question. And so the session middleware, which is one of the things that we want to connect with Socket.IO, is basically Connect. It's not Express. So to that end, we— yeah, and there is a project already for that. But my other thing is the ability to connect the templates to real-time events, and to that end, we need to make it Express. And there's also the fact that not many people use Connect without Express while leveraging the session middleware. You might want to use Connect if you're, like, just serving static files or static pages like HTML and some images. You might just want to use Connect. But when you are actually leveraging the session middleware, you're probably using Express. So I just went with Express.io. How are you going to do testing? So he's asking about how we're going to do cross-browser, cross-platform testing. So for our company, we also have the problem of supporting multiple browsers. And we want to have acceptance testing that makes sure that things work on WebKit, which is the browser we develop on, but also IE6. So we created an adapter. For Node called Soda. What Soda does is implements Selenium and potentially, if you want to use Sauce Labs, Sauce Labs is a startup that provides a service for automating testing with Selenium on the cloud, in the cloud. So instead of you setting up your own cluster and your, like, set of computers running Windows and IE and all the different variations of combinations, you can use Sauce Labs and you pay per minute. And it's also free for Linux and Firefox. So you can get started doing acceptance testing with— that way. And that's what we're going to leverage. So we're going to write unit tests. And we're also going to connect to, like, a fixed Socket.IO server. And we're going to just basically produce output to that page. Then Selenium will connect to that page and check for a number of positives and negatives. And if it fails, Sauce Labs will give you a video of what happened. So you can know exactly, like, OK, what test failed, or what's the output, or what's the JavaScript console saying. He's asking if it's been difficult to keep up with the WebSocket spec. And the answer is actually no, because at first we had a GUILLERMO RAUCH] So in the very first Node days, there was no HTTP upgrade event. So we had to implement WebSocket as a net server. So the HTTP parser and the HTTP Node implementation didn't give us the hooks to have a WebSocket server without a patch. So initially Socket.IO, you had to patch Node to have a WebSocket server on top of the HTTP server. Otherwise, you would have to run it in a different port. So then we had to support the initial spec, which was draft 75. And after that, shortly after, we had to support draft 76. And since then, the spec hasn't changed at all. Now it's going to change, and it's going to change in some pretty major ways. But the struggles with WebSocket have not been mostly implementing the spec. It's been, for example, the fact that they are supposed to bypass proxies. That's one of the design goals of the WebSocket protocol was we need to make this thing bypass proxies that are on the internet today, which is not the case. So WebSocket fails. So Socket.IO needed the machinery to determine, oh, I couldn't connect with WebSocket. I'm going to try something else. So on that end, it's been a difficult decision to make WebSocket the first choice because long polling ends up being more reliable for most use cases. But hopefully that's going to change now with the new spec and that should be the definite one that Firefox expressed interest in implementing and so does Chrome and Safari and IE9. So IE9 has the same ambition to implement this spec and today they are doing it with Silverlight or through, like, Labs plugins, but hopefully it's also going to be part of IE9. All right. Thank you so much. I'm going to post the slides to Twitter if you want to see them later.