 Real-time web, what is this thing? It's magic. It's the awesomeness from the future. So if you look at the history of the web, the web started as a place where you could share documents. You could just keep static documents. There was nothing dynamic about it. HTML files came in. Markup came in. It became a little jazzy. But still not cool enough. People wanted more dynamicism. So server-side dynamic stuff came along. CGI, Perl, ASP, PHP. But it wasn't good enough. You needed something on the browser also. That's when JavaScript came along. There was a browser war. Internet Explorer came along. And the pains to all our lives came along. But that also wasn't good enough. We needed to change the page content without refreshing the page. These portions of it. That's when XSR came along. Some people thought it was the end of it. We had dynamic stuff at the server-side, dynamic stuff at the client-side. But they were wrong. That's not the end of it. And that's when the WebSockets came along. WebSockets is the future after all this. It's the next big thing for the web. What is this? What is this WebSocket thing? WebSockets are bi-directional and full-duplex communication channels for your clients on the browser. How many of you use Gmail? How many of you chat on Gmail? So when you chat, you type in a message and the other person immediately gets it. And when they chat, you get it. And if both of you are typing at the same time, you still see it, right? The person is typing. It's full-duplex. It's bi-directional. It's a communication channel. It's in use. You use it every day as a user. It's about when you start using it as a programmer. It can be used for multiplayer games. You can have really, really large games with thousands of players. You can have users pinging each other, sending locations, starting with each other, sending scores, fighting, blah, blah, all kinds of stuff. It's really good for communication for multiplayer games. It's good for live and instant updates. How many of you use Twitter? How many of you have a mail ID on any mail provider which is modern enough? You see, in older days, you had to refresh your page to see if your mail you had new mail. Now, you don't have to do that. Immediately after you get a mail, you get a notification saying that you have a certain mail. The server pushes information to you. Meet your mobile phone, meet your browser, meet your tablet. The server pushes information to you. This is what's used today. Web sockets. Instant information to the client. And they're available on the most modern browsers. So, you're almost ready to go. If you have an application that has good amount of traffic or to add any of the cool features mentioned here which are mostly updates, you can start using Web sockets. And they're pretty awesome. What does the code look like? Don't get into the detail. So, you create a new instance of the Web socket. You see where to connect. Then you see when the connection opens do something, when the connection closes, do something. And when you receive a message, do something. That's pretty much the whole interface defined for Web sockets. Don't get into the detail. This doesn't matter. If this also went, all of us are already using them. Well, first of all, browser support. Though Firefox latest supports them, Chrome supports them, Safari supports them, IE10 supports them, Opera supports them. But we have a lot of people who are on really, really, really good browsers. And that doesn't only include the world of browsers. That includes how many of your Android phone users here? Congratulations. You're using the IE of the mobile. It's one of the worst mobile browsers today. It doesn't have Web sockets support. It doesn't have a lot of things. So, what do you do about it? The second problem is, it's a pretty new technology and there are a lot of flaws and a lot of security issues in it. So, there are multiple drafts. Everybody was creating their own drafts. W3C had multiple drafts. WJ had different drafts. And there are slight differences in the communication protocol. So, if one browser implemented somehow and you implemented in the server side how to communicate, the other browser will not work. That's pretty shitty, right? I mean, you write for one browser and the other browser doesn't work. And that's just one version of browser. Chrome 14 works. Chrome 17 doesn't work. It's painful. When the prefixes. Mozilla said, no matter how good this technology gets, we are going to put it on a stick with a dash mode in front of it. It cannot be new Web socket. It has to be new dash mode Web socket. There's only one. And, of course, earlier drafts had security loophole. So, you cannot use earlier drafts. Well, there will be ready in a year or two. But, you're right here. You're talking about it right now. Why not use it right now? Let's see. We'll go ahead and figure out ways of using it right now. Is it readable? Why even talk about something that's unusable today? Okay? Does it make sense? Using something that's unusable today? We have all the hackers here. We use unusable stuff to make it usable. So, there are a lot of tested alternatives available. The Web socket is pretty new. It's like, the draft is two years old. The implementations are about six months old. But, people have been doing these things for more than two years. There have been chat climes on internet for almost a decade now. How many have used Miibo? And, it pretty much works, right? How does it work? WebSockets is a new thing. How did it work in the olden days? Well, you didn't have a full duplex bi-directional communication channel before. You had full duplex unidirectional channel before. And, they were hacks. WebSockets came in to replace those hacks. These are the lists of hacks available. So, there's something called Comet. There's the Bex protocol. There's the Bosch protocol. There's a Jack's push engine. You can use any of these existing solutions to implement real-time communication in your web page. These are older hacks that ran even on IE4. So, they're quite tested. They're well proven, well tested solutions. WebSockets just tries to remove all these hacks and put something very standard so that everybody implements it so that our lives become easier. A lot of people, how many people are from DirectI here? A few? Okay. You guys already use Bosch protocol, I think. Quite a lot. And, these solutions use fallbacks like AJAX, what everyone uses already. iFrames, which existed before AJAX happened. And, if you don't want to use either of them, you can have a Flash object which implements WebSockets for you. So, that's one of the cool things about Flash. No matter how much we talk about Flash stocks, Flash is awful. Flash lets you do what today's web standards are not capable of doing. Estelle Pipe is only so good today. It might become really awesome tomorrow, but today we need that Flash fallbacks. And, we've been using these tools for ages now. If you use, look at any finance websites, well, not the Indian ones. Any of the American finance websites, they use these tools to push stock updates. You don't have to publish a page to see one stock update. As stocks update, partial pages update automatically. Gmail sends you messages, Twitter sends you updates. People have been using for ages. Well, we have been just fine. There hasn't been any pain. These things have been pushed along while we use WebSockets. Why do we need WebSockets? Well, these solutions are good by the hacks. There are a lot of problems with it. If you use a Flash fallback, it comes with a huge chunk of OSW5. You don't want to increase the payload. If you're using any of the other solutions, it's unidirectional. It's not bidirectional. And, of course, they have their own benefits and issues. WebSockets tries to standardize all of them together into one single standard, make them process, implement them, so that our lives become easier again. Some of them are not scalable. If you're using Comet, or you're using VEX protocol, the implementation is available. Don't use even-tread servers. How many of you know about Node.js? EngineX. And you've seen the history of how Apache couldn't scale beyond a certain point because it was multi-processed. Then certain servers couldn't scale because they were multi-credited. And then suddenly these servers came along Node.js, Engine.exe, and so on and blah. We have infinitely-scaling machines. That's because for high throughput, you need evented servers. None of these implementations use evented servers. You can have a chat server which can serve 100 people. Maybe 200, maybe 500. Not 10,000. Not 100,000. So you need something that could handle so many connections. So neither of these solutions are scalable. Do you mean that evented servers are the only way to get high throughput? Not really. That's quite debatable, but they are one of the good ways of getting high throughput compared to the other classical solutions available. So how many of you use rounded corners 10 years back, 5 years back, 3 years back? Do you remember how you used to put B tags where there were some round-eiser plug-ins and all? There were a lot of hacks to do rounded corners even 10 years ago. But now you have border radius properties here. The standards are not about creating new solutions. It's about taking existing solutions and putting them in one place in a very standard way so that you can save your time. You don't have to go around re-implementing the hacks. WebSocket says exactly that. Putting all these hacks together in one place so that you can save your time and do something much, much better, much more awesome. Of course, it saves money also. They're all billable. But it will take forever to standardize. W3CE is an awesome body. It takes years to standardize anything. So what do we do? What we can do is we can write a wrapper that connects to WebSockets if available. If not, then probably connects to a Flash-based WebSockets if available. If not, then we connect to iFrame-based solution. If not, we can connect to XHR polling. Many, many solutions available. You need a system that can take care of all this together in one place. You need a wrapper API that takes care of all this. It should be simple to use. Of course, if you want to use complex API, that's your choice. Use the WebSockets available. That's the biggest point. If WebSockets is available, use it. None of the existing solutions like Bosch or Bayox use WebSockets. And fall back to the next-best transport available. If not available, then the next-best. And most importantly, scales whether the server side. We're talking about end-to-end solutions, server side and client side. That's where socket.io comes along. So socket.io is this wrapper over WebSockets which uses all the other fallbacks that are available. And integrates very well with Node.js. If you're any of you who are early users or scalar users, there are socket.js bindings available in those languages. Socket.io is a server side as well as a client-side library. That's exactly what we need. It works in i5.5. I don't know if any of you have user side in i5.5, but it still works. It has a simple API, and most importantly, it's consistent across server and client. If you're writing code on the server and the client in JS, it looks exactly the same on both the sides. So it's very, very, very clear to understand what the code is trying to do. If you're a front-end guy and you have to jump into the back-end and it's written and twisted with Python, you might have problems if you don't know Python. Here, it's exactly the same API on both the sides. So for you, there is no server side, there is no client side. It's all one huge chunk of JavaScript. So it's pretty easy to implement, pretty easy to maintain if you're a JavaScript person. And because it uses evened servers, it scales really, really well. I mean, really, really well. I have tested it for more than 100,000 connections on my laptop. Of course, that's our artificial benchmark, but it works. And it has a lot of plugins. It is free and it's open source. You find a bug, you commit it, you do something missing, you create a plugin, you submit a patch. It's all open source and free to use. The server side code, should I zoom in? The code is not as important, I guess. So the code simply says you require the bucket at our library and you say listen to a certain code. And then you say on connection, you get a socket instance. So whenever a client connects to the server, the server gets an instance of that client, a kind of a handle on which the server can operate. And then you can send messages, you can receive messages. The handle that you get is the bi-directional channel. You can say emit an event or you can say on event, do something. It's just like how you write decoder, JavaScript code. Pretty similar. Very similar side and very similar on the client side also. Okay, I don't think there's Wi-Fi here. What I can do is, I have implemented a quick demo, which is the slides itself. So as the slideshow person, I can navigate any person who has the same post open anywhere else, and slide with me. Everything is synchronized everywhere. If there was internet, I would have known it, but I don't know what it is. Yeah, that's what I'm going to do now. I implemented a small security thing so I'll make sure that nobody else can slide my slides. I don't want everybody to be sliding everybody else's slides. So the page has Panami code. Up, up, down, down, left, right, left, right, right. And if I slide now, if you had the page open, you would see this with me. If you're not even in this room and watching a video class, you could see the slides. Isn't that cool? The idea is, I implemented... So the slides was already there. I just implemented a small code that takes care of all the communication. And, I mean, you wouldn't think of a slide doing any kind of communication, but the truth is, everywhere, application out there can have some kind of communication. And you can use WebSockets to implement that. Let's say if you have... How many of you have any kind of SMS-based... SMS-based application out there? Now, after the SMS regulation, you can't really push messages. What you can do is implement our client app that's what connects to your WebSocket server. And instead of sending SMSes to the user, your WebSocket is to push real-time messages. Or you can implement chess. Or you can implement checkers. Or you can implement any multiplayer game. So, essentially WebSockets is all about Bidation, communication, and full defense. And if it again today... That's it. Q&A. Q&A. So, this question is, why can't we use push.app instead of using socket.io? So, push.app itself uses WebSockets. And it uses all these fallbacks also. Socket.io is just another library that lets you post your own server. Push.app runs their own server. Instead of using your own server, you can use... Let's say if you want to compliment only the client side. You can use... And only server side you need it was the communication part. You can use push.app. Q&A. How heavy is it on the wire? As in, if it's a WebSocket talking, will the data transferred? I mean, is it compressed? What is it? So, before WebSockets, you use XHR and all. And in that case, you had to request every time. And when you request it, you send out headers, you send out cookies. In WebSockets, you don't send out anything. You have a persistent connection. All you send is just a message. That's it. Plus, of course, four bytes in the initial part for the database. So it's good for entire services, communication or something like that. Socket.io is about having a client and a server side. WebSockets itself is about also... You can have a desktop client talking to your server. You don't need a web browser. You can have a GGS bindings for WebSockets. And you can have a NoemShell extension that probably listens to some WebSocket service and shows you a notification. That's possible. It actually WebSockets violates HTTP 1.1. There are no cross-domain policies on WebSockets. So you can communicate cross-domain? Yeah. Using proxy. I mean, your server can act as a proxy. Of course, you can't communicate between two machines that are behind NAT. I mean, some guys sitting in one college and others in another college, they can't directly communicate. They have to go through a NAT. When they go through a NAT, they need a physical machine to merge the traffic. That's your server. And if you use Node.js-based solution, I mean, it scales quite well. Unless you're targeting millions of users, in that case, you need multiple servers. But from the NAT privacy, can a browser host WebSocket service? No. A browser is only a WebSocket client. You can connect to a WebSocket and then do things on messages. That's it. You can send messages. You can receive messages. So you can draw a parallel between flash media server and... I've never used flash media server. Flash media server. Oh, you said like, the whole wrapper library falls back from WebSocket to SWF to three other methods, right? But the bottom-up is methods are only unidirectional. Yeah. Whereas the top-ups are bidirectional. So how is this wrapper, you know, suppose I'm an I and I don't have SWF either, you know. How does a bidirectional communication work? When you say bidirectional, what you do is you open a connection. Let's say it's WebSocket and person sends message, he receives message. Now the WebSocket is not available. So what you do is you open an iFrame in which the person keeps listening until there's a message. So there's a server-to-client unidirectional message available. For client-to-shower, you can do a... No, a normal HTTP request. Okay. So it can be bidirectional using a normal HTTP request and these fallbacks together. But is that also called cross-domain? That won't support cross-domain. So what about firewall considerations? Since it runs on port 80, unless your firewall is blocking a particular site on port 80, it will work. So everything gets turned on through port 80? Yeah, so it's an HTTP handshake and after that it's a TCP channel on HTTP. So that channel remains open and you can communicate on that TCP channel. So it's not like a traditional software? It's not a TCP socket by say. It's an HTTP socket that remains open and then you can keep communicating over it. So what are the security threats that you talked about? That security is the problem. What's the problem whether it is WebSocket? I don't really remember the security that was in the earlier drafts. What else is supposed to open a channel and on the server, I can close the channel. So can you close from client to close the channel? Yes. Can you repeat that? Can you repeat the question? So this question is, can you close a channel from the client side? Yes, you can. Both parties are capable of closing the channel. It's yet another TCP channel. Both parties are capable of closing the channel. So that way whenever you navigate out the browser will automatically close it? Whenever you navigate out, you refresh the page, you do anything that changes the page. It closes the connection. Was it possible to close the connection via time also? You can close it yourself also. You can call the close method on the WebSocket as well. This question is, does it support SSL? Yes, it does. So when you connect to WebSocket, WebSocket protocol starts with WS code and slash slash. We want to use WebSocket secure. It's WSS code and slash slash. It runs over HTTPS. Always on channel mode? No. Polling does. If you use any of the older methods where it keeps polling, is there a message? Is there a message? That requires DNS lookup, then establishing connection and all that. That takes much more battery. This is our ideal connection. It doesn't take as much battery. Exactly, so you don't use them over Apache. Plus Apache will never implement something that breaks HTTP 1.1. So there are no patches. You cannot have WebSocket server running on Apache. This question is that can you have, if you have Apache running as a server for WebSocket, you learn out of resources because Apache is multi-process or multi-thread. Is it multi-process or multi-thread? So Apache has multiple MPMs. It has an event at MPM also. Apache has this concept of MPM multi-process manager. Apache has multi MPM for process, for thread and for event. Does it support SBD like? Not really. SBDI is a completely different thing. SBDI is like HTTP was going one direction. SBDI is another one form and WebSocket is another form. WebSocket is about communication. SBDI is a persistent channel where you can serve resources over it. Not really because that connection is open only for service. They will be using WebSocket also for the SSL connection initially. Probably the later handshakes can be... No, no. There are no plans right now. What are the ways in which authenticated data can be used? The question is what are the ways in which you can send and see authenticated data. So you can associate your session ID with the client ID on the server side. So every time a client connects to the server, the server gets in the handle of the bidirectional channel and ID to it. And you can associate... The client can also send a session ID which we have in the cookie and then you can verify that session ID and then create a map. This session ID is this user ID. Now the number is that. Pardon? How number is that? As much as your cookies are. Use SSPPS if you don't want it to become. My accession... BitBoy is working on the server side. WebSocket. We have used WebSocket. We have access to the cookie letters and the API. So this question is if you are using WebSocket, will you get headers and cookies? As I said WebSocket is a persistent connection. The headers are not sent again and again. The headers are only sent initially. If you pass the headers, you pass the cookies and you save them. Of course you can reuse it. You can associate it with the handle I told you about which has the client ID and bidirectional channels available. You can store cookies there. But on every message cookies are not sent. They are sync sockets. Similar to sync sockets. What are sync sockets? They are like non-blocking. The entire code here is non-blocking. Socket.io itself implements everything and non-blocking. The client side WebSockets is non-blocking. Is there a blocking socket? No. WebSockets is completely asynchronous. There is no synchronous WebSockets API. browser doesn't implement XR or XHR doesn't implement any network API which is synchronous. Isn't it because JavaScript itself is single threaded? Yeah. It will freeze your browser. It will freeze your browser. You can fire as synchronous XR request but that will freeze your browser. So it's not a recommended way. Another use case for WebSockets is let's say you have a let's say you have a Facebook user and you say I need all my data back. Facebook said it will take two hours to generate the data. And then you go refresh. Is it there yet? Is it there yet? They don't notify you back. You don't want to send that 200 MB or 1 GB of data over WebSockets. They can send a notification saying data is available. Download now. So your browser can keep listening to a WebSocket stream and on certain message can download much larger data. WebSockets is just for sending smaller messages. Everything that you send on it has to be serialized. You cannot send binary data. You shouldn't send binary data on it. You can send blocks. Why should you send binary data? All encoded data. So you can. You can send blocks. The API lets you do that. But let's say you have an MBO binary data. You're blocking the entire server. Only if you produce everything it doesn't bother you. So there is actually a connection which we have. And the video which we are streaming. So basically which I had I don't have that video header inside what is coming soon. So that's why it's like streaming. So in the same way we are doing here. So if you are talking about the downloading and the biggest problem is when you're running a WebSocket server it's an application server. You don't want the application server serving static content. Put it on a damn CDN and use it. So if I want to say use a WebSocket based API for notifications. How do I know that the user currently has an open socket? Suppose I want to say fall back. If the user is currently not sitting in the browser send them an email. Otherwise just show it on the browser. So the moment a user disconnects the moment user disconnects you lose the socket instance. So then you have to go save it. You have to keep a map somewhere that this user has the socket ID right now. If there is no socket ID that means the user is gone you can probably send them an email about it. How many of you are going to use WebSockets? Please do something more. Use it please. It's really cool. Any other question? What are some node.js servers for Java? No node.js. So socket.io So socket.io has server-side implementations. It uses nio libraries and all. So you have async servers in Java also. It works quite well. Wasn't there something about socket.io and Apache? Yeah, so this question was if you use WebSockets or not socket.io if you use WebSockets server with Apache, won't it get out of resources? Well, because you don't even use MPM with Apache mostly. But does Apache support WebSockets? So what's the workaround? There is no workaround if you're using Apache. You can use a patched version of Nginx so push it up uses node.js proxy. So suppose you have a VPS with a single IP address and you use Apache with everything else. How do you get socket.io working on? You put Apache on another port and you put WebSockets.io in front of it. A load balancer. Can't you put WebSockets on a separate port from AT? You can. But then again, certain NAT block is not working. How did you implement the authentication for the slide changing? So I put a check saying that if I'm the admin and that admin thing is enabled when I enter the Konami code. How many of you are old SNES players no Konami code? Up, up, down, down, left, left, right, VH. You do it on Facebook, you see a lot of circles and all. They still have it I think. I'll probably push the code for the slides on so you can have a look if you want. You don't have a LAN or the LAN that works. Both WebSockets will be same content as cross-origin No. If you're using the callback WebSockets itself, no. I don't think you can use a different domain or a different port for WebSockets. You can use a different port, you can use a different host. You cannot use a WSS from HPV. WebSockets can even Flash-based can if you went into that cross-origin XML file, but callback is not. Can you repeat that again? The question is, does WebSockets let you do cross-origin requests? WebSockets protocol itself lets you use a callback stone. So what's stopping it from being a security breeze then? I mean, how do you build security if cross-domain requests are allowed in WebSockets? Again, you have to implement some kind of authentication system on your servers. So, you can have something like a private public key thing. You can share the private public key with the user who wants to use that and they'll send a public key and then you verify it. WebSockets protocol itself is extremely minimal and it doesn't say anything about authentication, authorization and all. So, it's not like JavaScript then because usually when you use JSON to get data, you don't have to authenticate from your own server because you know that only that base can call. It's kind of like JSONP. JSONP you don't have to authenticate authorize, right? But you don't have to. Any more questions? That's it. Oh, did I mention my name is Aditya and my handle is Netroy on Twitter and GitHub. Thank you. I think I also built the JS for WebSci. I built the JS for WebSci. Thanks guys.