Adding Socket.IO support to our server

We have now reached the point where we are ready to bring Socket.IO into our server and create a running server implementation. Run the following command to incorporate Socket.IO and the related DefinitelyTyped definitions:

npm install --save socket.io @types/socket.io

With these definitions available to us, we are going to bring Socket.IO support into our server and begin running it, ready to receive and transmit messages:

export class SocketServer {
public Start() {
const appSocket = socket(3000);
this.OnConnect(appSocket);
}

private OnConnect(io: socket.Server) {
}
}
new SocketServer.Start();

The parameter that our OnConnect method receives is the starting point for receiving and reacting to messages in Socket.IO. We use this to listen for a connection message that will indicate that a client has connected. When the client connects, it opens up what amounts to a socket for us on which to start receiving and sending messages. When we want to send messages directly to a particular client, we will use methods available from the socket that's returned in the following code snippet:

io.on('connection', (socket:any) => {
});
At this point, we need to understand that even though the name of the technology is Socket.IO, this is not a WebSocket implementation. While it can use web sockets, there is no guarantee that it actually will; for instance, corporate policies might prohibit the use of sockets. So, how does Socket.IO actually work? Well, Socket.IO is made up of a number of different cooperating technologies, one of which is called Engine.IO, and this provides the underlying transport mechanism. The first type of connection it takes, when connecting, is an HTTP long poll, which is a fast and efficient transport mechanism to open. During idle periods, Socket.IO attempts to determine whether the transport can be changed over to a socket and, if it can use a socket, it seamlessly and invisibly upgrades the transport to use sockets. As far as the client is concerned, they connect quickly, and messages are reliable since the Engine.IO part establishes connections even if firewalls and load balancers are present.

One of the things we want to provide for our clients is a history of the conversations that have gone on beforehand. This means that we want to read and save our messages to the database. Inside our connection, we are going to read all of the messages for the room the user is currently in and return them to the user. If a user has not logged in, they will only be able to see messages where the room has not been set:

this.messageDataAccess.GetAll({room: room}, {messageText: 1, _id: 0}).then((msgs: string[]) =>{
socket.emit('allMessages', msgs);
});

The syntax looks slightly strange, so we will break it down step by step. The call to GetAll is calling the general-purpose GetAll method from our DataAccessBase class. When we created that implementation, we discussed the need to make it more general purpose, and to allow the calling code to specify what fields to filter on as well as what fields to return. When we say {room: room},  we are telling Mongo that we want to filter our results based on the room. We can think of the equivalent SQL clause as being WHERE room = roomVariable. We also want to indicate what results we want back; in this case, we only want messageText without the _id field, so we use the {messageText: 1, _id: 0} syntax. When the results come back, we need to send the array of messages over to the client using socket.emit. This command sends these messages to the client that opened the connection, using allMessages as the key. If the client has code to receive allMessages, it will be able to react to these messages.

The event name that we choose as the message leads us on to one of the limitations of Socket.IO. There are certain event names that we cannot use as a message because they have been restricted due to them having a special meaning to Socket.IO. These are error, connect, disconnect, disconnecting, newListener, removeListener, ping, and pong.

There isn't much point creating the server and sending messages if we haven't got anything at the client end to receive them. Even though we don't have all of our messages in place yet, we have sufficient infrastructure in place to start writing our client.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.189.2.122