 So the talk is all about building real-time applications, real-time web, which is essentially the future, as many would say now. Why is it the future? So to understand the future, we'll have to look into the history first. The web started as a medium to serve static content on the internet. Internet existed much before the web started. It just meant serving HTML documents, nothing more than that. And some people thought, well, these static documents are not of much use. There should be some dynamic stuff. So server-side dynamic content came. There was CGI, Perl, then Java came, PHP, many languages came. In 95, another language came, JavaScript. But the intent was different. It wanted to introduce dynamic behavior in the browser itself. So good, so far so good. New thing came along, Ajax, and the whole scene completely changed. We saw Gmail, we saw the new Yahoo Mail, how single-page applications were possible. You didn't have to change your page to change content, but that's not enough. That's OK for 2005. We are in 2011 now. We have to go real-time, and that's where WebSockets come in, and that's what this whole talk is about, building real-time applications using WebSockets. What exactly is real-time? Before I go further, I'm sure pretty much everyone of you use Gmail, right? And there is a G Talk pop-up window at the bottom where you can chat on. Do you ever wonder when you type a message in it? It happens all in real-time. You say hi to someone, he gets a message instantly. In the classical Ajax methods, you had to poll. Is there a message? Is there a message? But that would be an insane amount of traffic for the server. They managed to serve that amount of traffic, but not through a classic polling mechanism. What they do is serve a push. Sounds fancy. A lot of people have been doing it. What is it? We'll go further and see. What is the WebSocket thing? So what exactly is WebSocket is, you guys would know TCP, right? And you have used probably a lot of TCP clients, messengers and IRC clients, and chat clients, and blah, blah. And essentially, they let you do bi-directional communication over TCP, right? But on Web, you couldn't do that. On Web, you needed a very traditional model where the client center requests and the server center responds. And there was no equality between them. The server couldn't say, hey, client, take this data. Client had to request for data first. What happens in WebSocket now is we're trying to break that limit. We're trying to create a system in which the client can pull data, as well as the server can push data. So it's bi-directional and a full-duplex communication channel. Cool. Well, it can be used to multiply games. I'm sure you've seen a lot of Facebook games. You see, let's say you're building a snake game, and you're trying to mix it up with Tron, the two snakes run around and hit each other. You can do that all real time using WebSockets. You can use this for live and instant updates. Use Google+, Google+, gives you updates pretty instantly as soon as something happens. That's all through WebSocket. Or I fall back for that. We'll see that later. The good part is they are available pretty much most modern browsers. So if you want to use them, they're pretty much there. You have to just start using them. And they're pretty awesome. So what does the code look like? What you do is you just say my new WebSocket, and you give a URL to the WebSocket URL. It could be HTTP, it could be WS, depends on what you're using. And then you say, when the connection opens, do something. When you get a message, do something. When you close, do something. It's not a lot. I mean, don't go into details here. Just to show you what you actually would write when maybe in 2015, because of the things you'll see later. You cannot do this today. There's a lot of problems with it. There's a good browser support. Firefox 4, Chrome, Safari 5, I-10, Opera 11. But a lot of you use IEs also. I6, I7, I8, and there's Firefox 3, 3.6, Firefox 2. There's Chrome 4, there's Opera 9, 10. And there's plethora of web browsers out there, including the suckiest Android browsers. You just cannot use them there. And you cannot tell your clients, please use a better browser. You just cannot. Or a better phone, you just cannot tell them. So you have to support all of that. That's why you cannot use the web sockets right now. Another problem, even if your browsers support web sockets, there are currently six drafts. There is draft 6, draft 7, draft 10, draft 76, draft 77. And each of them is different. I wrote an application two days back and Chrome updated to draft 10 and it's broken. There are web sockets. I'm not using any older technology. I'm using web sockets and it's still broken. So even in the modern browsers, you cannot write consistent code. It's a pain. It won't be in a couple of years, but it is right now. Another thing, if you're using Firefox, then you have to use vendor prefixes, but that's okay. You can put a check for that. And if you use earlier drafts of web sockets, there are loop holes which could be used as exploits. So I'll no go. We cannot use this right now. We just cannot. What we can do is wait for a couple of years. But that doesn't sound sane. I mean, Gmail is using it. Google Plus is using it. Facebook is using it. Everybody's using it. Twitter is using it. We have to use it, right? Well, there are few methods you can use as fallback. There are a couple of things that've been using. People have used for almost about seven years now. There's something called Comet D. There's a Bayerx protocol. There's a Bosch protocol. There's a JAX push engine. They don't let you do all this stuff. They use older technologies to simulate web sockets. They're not pretty good, but they have a good support. But the only problem is, they're quite fragmented. If you're using Comet, you can push data, but it's not actually a full-duplex, bi-directional communication channel. It's just server-pushing data. For chats, you want bi-directional. I want to send data. I want to receive data from the server. So they're okay. They're not great. They all use fallbacks like XHR, polling, iFrames, or Flashbase, WebSocket. Well, it doesn't really matter for the details here. And a lot of people have been using them. I'm sure you pretty much come across all of these, at least one of them, every day. I'm sure. So we've been doing this for six years, seven years, and why do we need WebSockets now? I mean, people have been working on it. It's working great. Everyone's happy. Why should we even worry about WebSockets? Well, you guys have... Did anyone of you ever do rounded corners back in 2003 or 2004? Cool. Did anyone of you did box shadows or opacity back in 2000, 2004? Yeah, so these things were painful to do before through hacks, but now they have been standardized. The same's true for WebSockets. Bidirectional channels were not there, but server push was always been there. So why not standardize it? Why write 20KB of code to do something when your browser can implement it, and we can just start using it? Reduces the costs, money-wise, effort-wise, manner-wise. It's good. So we actually do need WebSockets. So all the solutions we know are currently hacks. So let's say if somebody using XHR polling, they fire an XHR request and they wait until a response comes, essentially blocking the servers they're using unless they're using an evented IO thing, which most of them don't. They have their own benefits. They have their own issues. Let's not get into the details here. Few of them are scalable, few of them are not. Like comedy doesn't scale. It's based on Java code which spawns threads, painful. So again, as I said, let's just standardize it and get it over with. Why should we even worry about this? Just standardize it. Cool. Standardizing, putting in every browser saves money, time, everyone's happy, but there's a small pain. Who standardizes it? ECMA, W3C, what WGG, what WG? Problem with them, the standard bodies take ages. It will take years to standardize anything. The 2022 would be the year of HTML5. We can't wait till then. We just can't. So we need some kind of a very simple API that just manages all of this for us. Comet is good, BIX is good, Bosch is good, but they're just way too complicated. So let's just write an upper API, it takes care of all this. It's simple. One, probably resembles a WebSocket API. Two, if WebSocket is available, it directly uses it. That's most important. Should use native when available. Fallback to the next best transport. So if you're using a system which has flash support, use flash-based WebSockets. You can implement WebSockets through flash, which is bi-directional by the way. If you use Xstart polling, it won't be bi-directional. And most importantly, use a solution which can scale well on the server side. Imagine writing a chat application and your server cannot handle more than 1000 connections. We're talking about persistent connections here. 1000 people on your side, 1000 connections. You cannot do that with your typical web servers. You need specialized web servers, evented web servers for this. So let's use something. Let's use socket.io. I mean, we are in the first ones figuring out this problem. People have been figuring this out for a couple of years. They have solved this quite well actually. What socket.io does is, it gives you a very consistent API across client and server. So I'll read it through. One, it uses WebSockets when available, which is pretty much most process. It sees for the drafts that are implemented. If it's draft 76, which you don't have to know. If it's draft 76, it operates on draft 76. If it's draft 10, it operates on draft 10. You don't have to worry about it. Your code will keep working. When the browser's upgrade, you don't worry about it. Socket.io takes care of that. That's what we want. We don't have to worry about managing a code on these trivial things. So it's good. Secondly, it works on even i5.5. I'm sure not a lot of you have clients who use i5.5, but still, i6 people, I mean, there are quite a lot of them in India, at least, right? So another good point. Third, if you write JavaScript, I'm sure you'll have to write JavaScript for the client side. Using socket.io's node client, you use pretty much same code on the server side. And so it's bi-directional programming. I mean, if we're talking about bi-directional communication, the code is pretty much the same. So it's very easy to learn. If you learn one side, you don't have to mess around the other side, unlike Comet, D, or Bayo, or Bosch, where you write JavaScript on the client side and you go worrying about the server side. It's a completely different language out there, right? And if any of you are lang fans or Python fans, you have clients available for socket.io in those languages as well. So it's not a problem if you don't have to switch a language. And since if you use the NodeJS socket.io client, evented.io, highly extensible, because socket.io lets you create extensions. Highly scalable. You can have 10,000 clients at the same time, just fine. You can have 20,000, just fine, 100,000, just fine. Of course, it depends on the servers you're using. I'm guessing on production servers, you have good resources. So, NodeJS plus socket.io for the win. This is what the server side code looks like. You just say, don't go much into the syntax, you just say on connection. This is my callback on the connection. I just took this code from the socket.io website, so I can just explain it. You just say on the connection, just emit a news message saying hello world. Somebody on the other side of the world in the browser will be saying socket.onnews, console.log, whatever data is there. Like this, console.onnews. So whatever you emit here, the event goes with the data to the client. I'm sure nobody will disagree that this is really simple. I mean, this is a piece of cake compared to what you have to do if you have to handle all the web socket shit that's out there. It's really painful. This takes care of everything. Works on an Android 1.6 phone. Works on i5.5. Works pretty much everywhere. You have a use case where you need to write real-time applications. This is what you need. Okay, I was supposed to show you a demo, but I can show you a demo. I didn't finish it. I was just working on the slides in the last session. So in the code, I've put two handlers saying, on slash next, emit an event called next. Okay. I say, so this is using express. There's an application which is serving this. I've just said whenever I hit the web server with slash next, on all sockets emit an event called next. When I say previous, emit previous everywhere. Okay. Understandable? Please, any responses? Okay. And in my main code, at the bottom, I say socket.onNext. I just say document or trigger next. And on this event, I am actually sliding the slideshow. So what I can do is, this is my slideshow. I can send the next. And it's a slides. I can say prev. And this goes to the previous one. Oh, sure. Is it visible now? Now? Actually much better. Yeah. So if I say previous on this, the HTTP handler is broadcasting to everybody who's opening the slide right now. Actually, I can push this code to one of my servers. Anybody using it in here? You have, right? Or this one person? Okay. So I can probably demonstrate it later to you. So this is actually running on one of the servers as well. So if you guys would have opened the website right now and I would have hit the URL, you would have actually seen the slideshow moving. I was, what I was trying to do was, if I, when I move the slides, the slides moves on your screen, which is probably, if you give me half an hour, I can do that. It's pretty much just 10 minutes of work, not that hard. Yeah. Yeah. You can say, you can namespace your events. You can namespace your clients. You can send it per client ID also. I mean, there are many ways you can deal with it. There are many use cases and this is quite a mature project and they handle all the use cases. Cool. Next, let me slide through the command line. Demo is done Q and A. The session was quite fast. Now I need 20 minutes of Q and A. So the thing is, since the message is really small, right? The what it malls is when you, when one person sends it, you just send it to the other person, right? It doesn't involve much of RAM because you're not spawning threads here. Node.js does it in a sync way. The system manages a thread, so you're not increasing any amount of RAM. Very negligible, pretty much null. I mean, I have benchmarked on my machine on I have a 512 MB machine and I benchmarked using AB and it was fine on 100,000. Get request. So on get request, I was broadcasting. I cannot do the WebSocket broadcast through AB and I can do get request. So I did like 10,000 get request. Each of them broadcasted something. That's the beauty of AsingGairo, right? I mean, if you're not doing a lot of memory allocation, you're not doing any kind of blocking. You don't, I mean, it's perfect. It doesn't take any resources. I mean, there are benchmarks with say, if Node.js does 10,000, Arlang probably does 50,000. So if you're an Arlang guy, go ahead. There are Arlang clients for socket.io. Please use them. They're really great. You don't have to stick to Node.js. This talk is not about Node.js. It's about building real-time applications and socket.io is our current resort. I mean, that's, we have to resort to because the WebSocket situation is really, really broken right now. Yeah, so let's say, I mean, socket.io is only because it's taking care of all the abstraction. Let's talk about benefits of using WebSockets. Let's say you want to do some kind of server push in the older methods. You do a request, right? First, that's the only other way, right? Server push or WebSocket. So in a traditional model, you, when you request, you send a huge chunk of headers, your cookies, your domain information, plenty of it. Right now, I'm just trying to send a hello world message. Why should I be sending some 2KBF data? Doesn't make any sense, right? On WebSockets, you're just sending what you need. One, two, when you're doing, no matter what kind of server push you use, what polling you use, there'll always be a little delay because you cannot keep consistently requesting, right? On WebSockets, the server is pushing the moment it gets the data. So you are, the client is not current, firing network request every three seconds, every five seconds is insane because DNS is slow, then there are network latencies. When you have a persistent connection, the communication is much, much faster. And since the size is small, it's even much faster. Pardon? So you can kind of mark the WebSockets that the class itself, I haven't found any, but I mean, it wouldn't be very hard if you want to, won't be. Yeah, but they, I mean, he's talking about testing the WebSocket itself. When you say new WebSocket, this URL, you should probably mark it, right? Yeah. No, there is no test available, I mean, test frameworks available for socket IO per se. I mean, it's not I have come across. So you can actually pass session information along. There is a session module which sends like a session ID and all. So the first time you want to authenticate, do it over HTTP. Once you do that, the client will probably send out a token saying, this is me. On the server side, you get the client ID and you can map the session ID with the client ID. After that, it's pretty easy. Yeah, it's a person in connection. If there are any glitches, the browser will probably try to re-establish. Yeah, that is per domain limit is there. Some browsers have four, some browsers have two. That's only for HTTP. This is an extension of HTTP 1.1. It's actually a violates HTTP 1.1. So it's not, it's not essentially strict HTTP 1.1. It violates it, so it doesn't stick to that rule. You can have 20 connections to the same domain, it's fine. Even in that case, I mean, can you tell me a situation and where you'd be actually establishing more than four requests to same domain? Why not just, I mean, it's essentially a stream. Why not just push it over the same stream? Even if it's access or polling, why not request data in chunk? Yeah, yeah. I mean, depends. I mean, you can have some persistent connections for some real-time updates like there's a new mail or there's a message. But fetching all the mail information via WebSockets, that's kind of a little too far, too far-pitched. I don't think WebSockets actually sticks to that limit, so probably the older ones, yeah. But again, then it's not a very long-lasting connection, right? When you do a polling request, it dies out in certain time. It doesn't try to keep it open for like half an hour, even if there's no message. So it dies out so that if anybody else might request for the same domain, it might be alive. You're not audible. Can you be louder? So you, if you want to send binary data, you'll have to serialize it. You can serialize in Bay 64 is the most common thing that people do. And you don't really need to deal with much binary data at least till today. I mean, there are a few ways, but you don't really deal with them today, right? From the browser? So anyway, whenever you're not in this situation, any situation when you have to send a binary data over network, you serialize it in a safe way. Bay 64 or anything like that would do just fine. Any more questions? Yeah, so if you're using Chrome Debugger, all the old, if you're using old versions of Chrome or WebKit or Safari, it will show you those XSR polling requests. If your draft version doesn't match with socket IO draft version, you again see the XSR polling request. But if you're actually using WebSockets, there's a tab for WebSockets in Chrome now. So you can actually see the WebSocket request also there. I mean, if you want to locally debug it, I mean, you debug it just like any other node application. You just start node with a minus debug flag. You do use the node inspector and just debug use again. I10 actually does. I9 doesn't. No, so socket.io is a library that works on top of node. Yeah, so what you can do is you can go to the GitHub page for socket.io. In the tags, you can see each version and you can probably go and see the package files. The package file mentions the minimum node version required. So new ones run on 0.47 and above only because there are a lot of event emitter changes in the latest node.io. The event handling is completely changed in the latest code. And it will be very different in the ones 0.6 that get released, very, very different. I didn't understand the last part, can you be louder? So you're saying instead of doing a broadcast, you want to do one-on-one communication. That's what the question is. So that's what I was showing you here. What I did was I did io.sockets.emit, which means that broadcast to everyone. But this is not the only one you communicate in socket.io or in WebSockets. When you establish a connection, there's a method called io.sockets.onConnection. And you get a client object here. So you can actually store the client IDs and all, create a map somewhere in memory, and you can use that to broadcast or to send out to a group or individual members also. No, no, the framework manages that. You don't have to worry about it. You just probably say, let's say you log into users and you can somehow manage to create a map here, saying this client ID is this user. You can just send a message to that user. It won't be very hard doing that. I mean JavaScript objects are maps. You can just straight use them. You can use sessions. That's one of the ways or you can make sure when you're sending the message there in the browser itself, you can send the IDs. That won't be very secure, but depends on your use case. Pardon? Oh yeah, so again, this is just the next step after Ajax. In Ajax, you can update individual sections. Similarly, it's true here. I mean, you have a WebSocket stream open whenever data comes. It depends on your handler. It's asynchronous. It's just like XHR. It's completely asynchronous. And the callback happens. You can either change the complete page or change section of the page. That's up to you. It doesn't deal with the DOM itself. It doesn't deal at all with the DOM. It just gives you a callback. You do whatever you want to do with your DOM. It doesn't do anything with your DOM. Yeah, so there are a few frameworks and a few libraries for Node that are right on top of socket.io, which let you do things like that. We let you bit portlets and all, and there's something called Node.js, which lets you, if you create a method function on the server side, it serializes that function, sends it to the client, the client evaluates it, and puts a function there. So on the server side, you just have to say, this function, and it automatically executes. It's like RPC. So all those things are possible. So you can, so it also has some UUIDs, but it manages them internally. You don't get them. Pardon? So I am not sure if there is a socket.io server available for Scala, but there's one for Java. So you can probably compile it and maybe use it. It would be a little tricky. So if you're using web sockets, I mean, it works fine behind any proxy if you're not using web sockets. XSR polling is normal HTTP, it works fine. But problem starts happening when you use Nginx or Apache or any of those old HTTP proxies in front of these applications, because this web socket is an extension to HTTP and it will break behind our traditional HTTP proxy. So the best solution is you can use a Node.js-based HTTP proxy and it works just fine. There's a website called Node.stuff, which is a free Node.js hosting platform, and they host about 2,000 applications on them. They've been serving a lot of web socket applications. It just works fine. So you need to use HTTP proxy that supports web sockets. There's the Nginx patch available. You can use that. Node.stuff, NOD. So it's an open source platform. Sometime it gets crowded and loaned sources. You can just clone it, deploy it on your own EC2 machine. You have your own Node.js platform. So it's a git to push, like git push to deploy. You just code, push, and it automatically restarts the application. That's the thing. You don't use Node.js for serving huge data or doing computation intensive applications, right? Okay. What you can do is instead, don't use web sockets for that. So there's a thing called server-send events. Yeah, let's say it's not there. Let's say it's not there. You can use socket.io to send an event saying, the file is updated. Please do a get request and pull the file. Yeah, so you don't, it's an immediate message and the server pulls it himself. He's not polling, right? Solves the purpose and you're not hogging the resources for socket.io. Yeah, it's a push-initiated poll, which is a big deal. I mean, let's say you have a ROM on your phone which needs to be updated every two, three days. Your server will say the new ROM is available. I mean, a persistent connection just gets a notification. Another connection will get open to just pull the data. You don't want, you wouldn't never want to push a lot of data on a web socket stream. Essentially, the idea behind this is given control to the server for pushing data. I mean, it's fine if it's a push-based poll or whatever. When the server has the control and can control probably like grouping requests together, let's say instead of sending one or two requests at a time, or let's say you have a homepage like Yahoo homepage or any of those older homepages and this has some 500 modules. Not every user is using all the modules, right? The server can just say, these modules are updated. The client says, I am stressed, interested only in these four modules. I'll pull only these four. So you update only those four. The server just says, what all is updated? So you don't, remember, you don't push hundreds of MBs on web socket stream. It's not meant for that. So when you create a web socket stream, you have to serialize information. When you have to serialize information, especially binary data, you have to put it in memory, right? 100 MB serialized will probably bloat up much more. Binary to serialized. I mean, you have to decide the limit based on your traffic and your server capabilities. Pardon? You put more RAM if you want to have push 100 MB, 100 KB of files. Entire voice data, yeah. I mean, because you, let's say if you want to push a new image, serializing it will be very, very, first of all, when you serialize it, it will take CPU. When you serialize it, it will take memory. When you do this push-based pull thing, you just have to pick it up from the file system and just send it out. Yeah, exactly, exactly. Exactly. So let's say I have a web server that generates screenshots. So I send a requesting, generate screenshot for this URL. It can generate the screenshot, put it on a CDN URL, and then I can fetch from there instead of sending it on the web socket stream. And the next time anybody requests, it can just directly come from the CDN itself. It's a huge difference. It's microseconds, it's microseconds. You will never, never notice it. You can probably even create a distributed map reduce system in which every browser gets a chunk of data, then the map around it, they send it back the information also to web sockets. It's all possible whenever they send back data, whenever server has new data, it can push again, it can build a farm based on browsers itself. Exactly, I mean, that also depends on the web servers you're using, how you're using them. I mean, that depends on a lot of factors, how you want to scale. There are a lot of factors involved. Louder, please. Yeah. So you start from finding the web socket. I mean, when you're doing any kind of request, you're managing this one ID across all web socket connections, right? You can actually map some kind of, like the transaction to that ID, right? On the server side, you cannot take care of network glitches. Can you? I'm not. Let's say the client starts talking about he has something, and he has a website request to the server for the work, and we need to push back your service to push back. So, Yeah, so whenever you get disconnected, there's a, even for that also. So here, this part here, when you're saying IO.Socket.onConnection function client, you can here say client.on disconnect, and you can probably just clear up the transaction, roll back at whatever you want to do here. Yeah. The moment, there's a timeout for it. So let's say if there's 10 seconds of a network glitch, the browser reconnects, nobody says anything, it continues, but let's say it's for 30 seconds, this will automatically happen. I think the typical thing is about two seconds or something. Yeah. So you can, you can, by the way, if you're using WebSockets, you can do it over like Secure SSL. You can do that. So there's WSS WebSockets Secure, or if you can do the traditional XHR and all over HTTPS also. So that half security is done there if you're worried about that. Any other questions? There is a little timeout that's defined in the spec itself. The WebSocket spec says how much time it should wait before calling the disconnect. Yeah, so that's definitely disconnect. You reload the page, everything on that page is gone. The DOM, the connections, everything. Yeah. Every time the page loads, you have to re-instantiate the connection. Oh, that's not related to this. We'll talk about this later outside. Okay. Any other questions? You're done here? Thank you guys. By the way, I'm NetRoy on Twitter if anybody wants to follow me.