Real-Time Communication with Sockets
What is Real-Time Communication?
Real-time communications can be defined as the exchanging of information between two or more users with less usage of network and devices in Realtime. If we use an HTTP Request using a browser the data received will be only shown after a request. While coming to the sockets Real-time communication the connection will be already established and can receive data without a request.
What are sockets?
Sockets are a protocol which is given as a proxy for HTTP protocol. Sockets are considered as an ideal mechanism for real-time communication as it reduces the overhead time which is required to process the metadata by the server in order to respond to a request, sockets also decrease the latency over the transmission channel.
What type of protocols are used?
Real-time communication with sockets uses its own protocol WS & WSS which means web socket protocol and web socket secure protocol just like HTTP & HTTPS and uses 80 and 443. web socket proxy is applied over the HTTP during the initial handshake between the client and the server.
Initial handshake takes place when a client requests the server for real-time service, This initial request contains all the headers required by the server to process the request. Once the connection is established web socket protocol is mapped over the HTTP to serve the further requests.
But the requests which take place after the initial handshake contains a lot fewer headers then before. This reduces the latency and also the traffic over the channel. Even with sockets, a client has to send continuous requests to the server but the issue of high bandwidth is resolved as the amount of metadata send with the headers of the request is a lot less.
What Socket.IO is
Socket.IO is a library that enables real-time, bidirectional and event-based communication between the browser and the server. It consists of:
- js server: Source|API
Main Features are:
Connections are established even in the presence of:
- proxies and load balancers.
- personal firewall and antivirus software.
For this purpose, it relies on Engine.IO, which first establishes a long-polling connection, then tries to upgrade to better transports that are “tested” on the side, like WebSocket.
Unless instructed otherwise a disconnected client will try to reconnect forever until the server is available again.
A heartbeat mechanism is implemented at the Engine.IO level, allowing both the server and the client to know when the other one is not responding anymore.
That functionality is achieved with timers set on both the server and the client, with timeout values (the pingInterval and pingTimeout parameters) shared during the connection handshake. Those timers require any subsequent client calls to be directed to the same server, hence the sticky-session requirement when using multiples nodes.
Any serializable data structures can be emitted, including:
- ArrayBuffer and Blob in the browser
- ArrayBuffer and Buffer in Node.js
In order to create separation of concerns within your application (for example per module, or based on permissions), Socket.IO allows you to create several Namespaces, which will act as separate communication channels but will share the same underlying connection.
Within each Namespace, you can define arbitrary channels, called Rooms, that sockets can join and leave. You can then broadcast to any given room, reaching every socket that has joined it. This is a useful feature to send notifications to a group of users, or to a given user connected on several devices for example. Those features come with a simple and convenient API, which looks like the image:
What Socket.IO is NOT
Socket.IO is NOT a WebSocket implementation. Although Socket.IO indeed uses WebSocket as a transport when possible, it adds some metadata to each packet: the packet type, the namespace, and the ack id when a message acknowledgment is needed. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a WebSocket server either.
Socket.IO can be implemented in many technologies like
A simple Real-time application can be built using technologies like NodeJS, ExpressJS, HTML.
Methods used in Socket.IO
Sending and receiving events
Socket.IO allows you to emit and receive custom events. Besides, connect, message and disconnect, you can emit custom events with your own event name.
Restricting yourself to a namespace
If you have control over all the messages and events emitted for a particular application, using the default/namespace works. If you want to leverage 3rd-party code or produce code to share with others, socket.io provides a way of namespacing a socket. This has the benefit of multiplexing a single connection. Instead of socket.io using two WebSocket connections, it’ll use one.
To broadcast, simply add a broadcast flag to emit and send method calls. Broadcasting means sending a message to everyone else except for the socket that starts it.
Sending volatile messages,
Sometimes certain messages can be dropped. Let’s say you have an app that shows real-time tweets for the keyword, Bieber. If a certain client is not ready to receive messages (because of network slowness or other issues, or because they’re connected through long polling and is in the middle of a request-response cycle) if it doesn’t receive ALL the tweets related to Bieber your application won’t suffer. In that case, you might want to send those messages as volatile messages.