 Today, I'm going to talk about programming in Sokotaio, which is the right of the dog. So a little bit about me. One of the founders of HushTube, actually was a gaming company. We make games primarily on Facebook. The popular game that we have right now is Sudoku Quest. That's our main focus right now. We primarily work on PHP, JavaScript, and CSS. The games are not Flash. They work on the browser and they use HTML and CSS. I've been a fan of JavaScript. I've taken my liking to JavaScript very recently. Primarily because of the advent of networks, frameworks like Backbone and Sokotaio. So I like JavaScript a lot and front-end or front-end. So we do a lot of that also at our companies. The other thing is, I would be a little fast probably. So if I'm very fast or if I'm too low, let me know. Any questions, please. This is like a personal thing why I started Sokotaio. There is a game on Facebook called Tetris Battle. It's a multiplayer game. I'm on the left side and I play with somebody else on the right side. So what happens is it's a Tetris game. Whenever you clear lines, you send those lights to the other person and they start building up. So this is like a real-time game that they develop. But this is primarily on Flash and we don't use Flash. We are using HTML and JavaScript. So we wanted to introduce multiplayer functionality within our games and the answer for it was Sokotaio. So one of the reasons why we started exploring Sokotaio and doing that. So a little bit before that, before I go into detail about Sokotaio, this is how the traditional web has been. So how many of you are game developers? So the traditional web has been a request-response kind of scenario. So we have a server and the client. So it's usually a case where the client requests for data and the server responds for the request. And that's how web has primarily been. There's no way for the server to send data to the client. There's no way for the server to push data to the client. It is only possible for the client to request data and the server then responds to the response back. So that's how it has always been. But games are very popular and real-time apps have become very, very popular. And this kind of architecture really helps a lot. But there have been some solutions to solve this problem. So some of the popular ones are in the comment. Comment is actually an umbrella term for a lot of technologies. So what they do is they use something called long polling. So what happens is the client keeps the connection open between the client and the server. And since the connection is open, the server can send data to the client whenever there is data to be sent. And after some time, the connection is closed and again reset. So this is how long polling happens. So a long connection is kept between the client and the server. And then the server wants to send data to the client. The server sends the data back to the client. So that is one of the ways in which push was implemented. And obviously flash is also one possible way. So you open a socket connection between a browser and the server. Since the browser will have a plugin, a flash player installed. And you can have a socket connection between that and the server. But these two don't really work well for multiple reasons. So comment is just a workaround for making real-time communication. But flash is an international story because obviously it doesn't work well on mobile devices. It doesn't support it. The future may not be flashed. So these don't scale very well. So that's when the sockets are introduced. So as the name suggests, they are sockets for the web. So one other problem with Comet and those kind of technologies is even though they have a lot of overhead. So for every connection between the client and the server, there are a lot of HTTP headers passed around. And it's actually a lot of waste of bandwidth and resources. So to overcome this overhead, web sockets are introduced. So it is a new standard. So it provides bi-directional and full-duplicate connections. So both the client can communicate the server as well as the server can communicate to the client and full-duplicate screens. They can happen at the same time. Without collision. So one thing with web sockets is they're not implemented everywhere. Only the latest browsers have web sockets in them. But web sockets are already standard and it looks very promising. Now SocketOS library is one of the libraries that implements web sockets. So socket.io is actually a very good library. It's an awesome library. It has a simple API interface to interface with web sockets. As well as the other thing about socket.io, it supports multiple browsers. It even works on IE6. So the way it works on IE6 and other browsers is so it tries to use web sockets. If it doesn't support, it fallbacks to other transports that are available on the browser. So it could fallback to flash. So IE has flash installed and it can fallback to flash. Or it can even go to long polling. It's nothing but Ajax request which keeps the connection open between the server and the client. That is one other way in which this can happen. So it keeps on falling back to whatever transport is available. There are like six different transports, etc. They can be polling and other stuff. So socket.io is this one good library with a simple API interface. It's also open source. A lot of companies are actually using it. This is just a simple introduction to socket.io. If you have any questions under this point, please ask them. So it jump into demo. So the demo program that I wrote was a very simple game. So it's a multiplayer game that we all usually play as children as kids. It's a very popular game. So the game is this that you actually have to connect the dots. It's a two player game. It's a turn based game. So you connect the dots and... So the way it works is you connect the dots and you found squares. So whoever owns the maximum number of squares actually wins the game. So I can actually show you the game. So the way it works is I farm a line. The other person makes a move. So once I close this box I own this box. So you get the idea. So this actually has been built over socket.io. It's a simple demo that I created. So you see that it is real time. And it uses web sockets because I'm using Chrome. But based on what browser you use, it actually also works on other browsers. I can show you a demo on other browsers where web sockets are not supported and still see how it works. So this is the basic game that I made a demo of. I'll just dive into the code. So I use a bunch of things. So I use Express. Express is another framework that is very popular. It is used to create a very... Does socket has to work on top of most disks? Yeah, it works on top of most disks. So what we basically do is we start a server and I listen on port 81. So port 81 is the one where you listen on. So that's when it starts... It accepts connections on port 81. We'll just skip this part for now and then I'll come to it later. So this is the part where we actually listen for connections. So we actually write on this connection even. And whenever a client connects to the server, this part of the port gets executed. So I have a socket for download connection. And there are three built-in events that socket also holds. One is connection, disconnection, the company calls message. So these are three built-in ones. But apart from that, you can actually create your own custom event. So connection disconnection is obvious. Whenever a client connects, it's connection. Whenever a client disconnects, it's disconnection. And message is when you want to send a message. So the API, if you look at it, is actually very simple. And register is a custom event that I have created. So whenever a client connects, it has to register with a nickname or something or other. So that's what registers. And once registration happens, we actually start the game. So that's simple. So I'll just quickly go through the code. So this is the registered part. This is the message part. And this is the disconnect part. So there is two parts. What I basically do is whenever a client connects, I put them into a queue. And when the next client connects, I put them again in the queue. And I take two people from the queue and match them to start the game. So it's on a first-come-first-basis. So the first player gets fined to the second player. And that's how the matches are created. So that's this part. So I basically put them into a queue. Then I file an event to see if there are enough players to start the game. And I basically increment the number of players. I'll tell you why this is good. Then I tell everybody that I send them statistics. I send them statistics like these are the number of players that are present. And these are the number of games that have been started. So if you want to send data to everybody who is connected, you can just say, I have got sockets for them. So that will send data to everybody that is connected. There are also other ways to send data to the player. So the commenter will pass here. So socket.blogtask.element will send data to everybody who is connected, apart from the person who initiated the connection. So it's like client A, B, C, all of these three connect. And we do socket.blogtask.element. And at that point, if the client C was getting connected, the data will only go to client A and client B. Client C is below first. And if you want to send data only to a particular client, you can do socket.element. So that way you send data only to the particular client. So in the context of the game, what we are actually sending, the data that we are sending is, the one thing is, I have the game, so obviously I have to send moves to the players. So that is one data that is being sent. Then there is chat, so people can chat between others. So that is the other kind of data that we send. The third kind of data that we send is statistics. Company players are the only games that are being started. Very basic, very useful. Just a question. What difference between iOS sockets and socket.blogtask? So iOS sockets. So socket is the client that is actually connecting. And iOS sockets is every client that they are connected to. Yes, so when you say socket.blogtask, it basically means that they will be doing the same thing like iOS sockets. So the difference between those two is, suppose client A, B, C and connecting in this order. A after B then C connects. So if you do socket.blogtask.inmit, since client C is connecting at that point, the data only goes to client B and client B. Client C doesn't get the data. But in case of iOS or socket, it's local to everybody. So the same statement can be done in this. So if I uncomment these two lines, it's the same effect. So the data to the first client that connected, the last client that connected, and the others. So I'm using the built-in message type for chatting. So when I use a chat for the other user, the message is sent between them. And move this whenever we make a move, the other person knows about it. And this connect is obviously when a player disconnects, the other people have to be notified of. We actually don't notify the other sockets, but we could notify the other sockets. So we just do it, upgrade the statistics of a number of players connected or not. So this is the socket airport that essentially needs to be built-in. So to write a simple server using socket.io, it's probably less than 10 lines of code that you need to write. Since we have a little complex game, it's not very complex, a little complex game. There's just little more lines of code. So your match is the event which you have connected? Yeah, match is the event that we have signed. That's what matched us. It's a custom event that you listen. One is the kit. It tries to look into the queue to see if there are enough players to start the game with. So in a broad level, these are the two things. You do socket.on, which means you listen for the event. Socket.inmit is your image of the event to the other player. So these are the two things. So when two players are matched, you do socket.inmit already, which means you're ready to start the game. And here if you see socket.on is when you're listening for those events. I'm running the server here. So whenever a client connects, we'll actually see what is happening. I've not put a lot of prints here. So I guess there's too much information here. Probably understand anything. Let's forget that. So these are the basic things. Then there's something else called a room in socket.on. So the point of rooms is, so if you don't have rooms, what happens is everybody gets to know what a room is. Suppose we have a game and we don't have rooms. So everybody will participate in a single game. So when you make a move, everybody comes to know of the game. So that's what happens when you don't have rooms. So in socket.on, they also have this terribly colored room. So we can actually join two players to a room. It's like a channel. It's like a private channel. And whenever you send data to the channel, everybody in the channel gets the data. So that's what is a room in socket.on. And the way to do that is, we actually don't get to that. So once enough players are present in the game, we can actually match the players in the room. So the room is a simple integer that I keep incrementing. It can be anything. For simplicity sake, it's just a number that is getting incremented. So whenever two players are matched, the room number will give me this. And that's how I also keep track of the number of games that I have started. So once you join two players or multiple players to a room, you can actually emit data to the room. You can send data to the room. So socket.on.com.com. So data.id is a room number or the room name. And then you will emit what data type it is and what data it is. If you're interested, actually, you can log into the app and save for yourself. So that's one name. I have a question. Does socket.io give you any help with dealing with race conditions? Like for example, let's say you're making a game where two cars are racing. So specifically what time, the exact moment that you make those actions are important. But considering latency and the fact that you won't get a reliable timestamp from the browser. Does socket.io help you or do you have to build in the logic? The socket.io doesn't provide you. It just provides the messaging interface. It only provides the messaging interface. So you have to take care of that. So when you said when a browser doesn't support WebSockets, it falls back to other stuff. Do you need to write any extra code for that or does it automatically take care of it? It automatically takes care of it. So it's a very simple API. It exposes these APIs and you don't have to worry about underlying transport. It actually takes care of it. And what about support for mobile devices? Mobile also works. So the latest browsers support WebSockets. I think IOS 5 probably supports. But the previous one at least supported is that which means they love someone. Can the client be used with other servers at findings like for PHP or Python? No, it can't be used. If they understand the protocol. So are there entries for like Python and? I'm not sure. It's again a protocol there. So if any client implements a protocol, yeah, it will work. But the duty is you can actually write code on the client and the server. In some cases you can actually share code between the client and the server. But isn't there an order which runs PHP and Node.js? Yeah, it is probably there. But what you could actually do is you could have a server which just takes care of notifications alone. So that way it actually scales very nicely. The way PHP works is it is process-based. Node.js is obviously called that way. So it supports a lot of connections. Another note about socket IOS. So whatever data is present is stored in memory. So whatever data it needs to maintain, it's stored in memory. So like the data like room number, number of players, all that is stored in memory. So what you could do is if you want to scale to multiple processors, which means you want to scale to multiple servers, you would want to share the data from multiple processors. So it also has other stores. So you can actually use Redis for instance. You can store the data on Redis and it can be shared on all those processors. That also can be shared. Can I use Node as my socket client? Like can I actually interact between two Node servers using sockets? Well, as a general, let's say I have two servers running and I want to communicate between them. Instead of HTTP, I want to use WebSockets. How difficult would socket IOS be with something like that? So the duty of socket IOS is you don't have to worry about what transport is being used. So that way it will use whatever is available. But you can actually force socket IOS on these specific transports. Let's say that if it doesn't support any of the other things, other than socket it's not going to come with us. I think the question is, if I have two server instances of Node.js running and if I want to communicate between those two, is it possible to Node.js? Because Node.js has to work as a client on the server. So from the client, you want to talk to two different servers? No, no, I want servers to talk amongst each other. Without exposing an HTTP behavior. Listen to me. I tried yesterday night and there was a message like RB2Message on the console. What are they? It's like the socket has to sound like regularly some message, right? Yes. So RB2Message is a way for the server to know whether the client is alive or not. So a lot of times what happens is the client may not understand you because of a bunch of reasons. The user connection got cut off something or other. So to know whether the client exists or not is alive or not. So RB2Message is actually all these can also be configured on the socket server. What is the right timing? So I think it's 60 seconds of the program. Last question. Did you have to solve this problem of authentication? Mr. Kedayu? Authentication? Authentication. Did you have to do that? No, I didn't have to do that. But software apparently supports a way to authorize and unshape. I haven't done it in depth, but because of the problem. Okay, so thank you. So we'll do a short break if you want to.