#socket io

Our everyday digital experiences are in the midst of a real-time revolution. Whether attending an event in a virtual venue, or receiving real-time financial information, or monitoring live car performance data – consumers simply expect realtime digital experience as standard.

What Socket.IO is Socket.IO is a library that enables low-latency, bi-directional and event-based communication between a client and a server.

It is built on top of the WebSocket protocol and provides additional guarantees, like fallback to HTTP and HTTPS long-polling or automatic reconnection. WebSocket is a communication protocol which provides a full-duplex and low-latency channel between the server and the browser.

There are several Socket.IO server implementations available:

JavaScript (which can be run either on the browser, in Node.js or in React Native)

Installation steps

API

Source code

Java: https://github.com/socketio/socket.io-client-java 

C++: https://github.com/socketio/socket.io-client-cpp 

Swift: https://github.com/socketio/socket.io-client-swift 

Dart: https://github.com/rikulo/socket.io-client-dart 

Python: https://github.com/miguelgrinberg/python-socketio 

.Net: https://github.com/doghappy/socket.io-client-csharp 

Rust: https://github.com/1c3t3a/rust-socketio 

Kotlin: https://github.com/icerockdev/moko-socket-io

App Development Tips From Our Experienced Developer. Also, check some of the tips shared by our developers who have experience working with top developing tools to create mobile applications with Socket.IO. Being the best mobile app development company.

What Socket.IO is not

Although Socket.IO indeed uses WebSocket for transport when possible, it adds additional metadata to each packet. 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 plain WebSocket server either.

Reliability

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. Please see the Goals section for more information.

Auto-reconnection support Unless instructed, otherwise a disconnected client will try to reconnect forever, until the server is available again. Please see the available reconnection options here.

Disconnection detection 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 multiple nodes.

Binary support

Any serializable data structures can be emitted, including:

ArrayBuffer and Blob in the browser

ArrayBuffer and Buffer in Node.js

Let’s conclude This module provides an easy and reliable way to set up a WebRTC connection between peers, and communicates using events (the socket.io-protocol). Socket.IO is used to transport signaling data; and as a fallback for clients where WebRTC PeerConnection is not supported.

Well, that’s how to integrate socket IO on many platforms . The package made it all easy. Thank you for reading, give it a clap or buy me a coffee!

Feel free to get in touch with us.

9/12/2018 - Day 2

Listening to: H.U.V.A. Network - Diagrams

I am now able to successfully control the Arduino board connected to my RPi through USB serial with a socket.io connection to the RPi from my remote terminal. Currently I am serving a small webpage with the slider with 10 possible positions. When changing the position of the slider, the value is emitted through the socket connection into the RPi. The socket connection in the API I have set up on the RPi then routes the value date into the socket.on() listener that picks up the new value and sends that value to the nodebot connection to the Arduino. I can now control the RPi and anything connected to it with javascript from anywhere with a network connection. In the future, I plan on extending this connection beyond wifi and making it cellular, so essentially my RPi will have no effective range as long as its within the range of a cell tower.

What was problem you originally pitched?

In January 1815, Napolean and the Duke of Wellington met to settle their differences over a game of table football. It was a long and heated match with neither side having a clear upper hand. After a few hours of terrific shots and fantastique saves, an argument broke out: The Duke thought he had just scored his 10th and final goal, whereas Napoleon said it was the 9th and the Duke had one more to go. With no way of keeping track of the score, the fight turned ugly and 6 months later gave rise to the battle of Waterloo.

We’ll never know what the actual score was on that fateful day, but we aimed to prevent disagreements like this from happening again. So we set out to augment the office table football table; a device that’s very good at hitting balls but very bad at tracking scores and playing sound effects. We wanted to build something that would capture and log goals, and add a couple of nice extras to make the office kitchen feel like Wembley

What did you build?

Hackball! We made a server with a fancy front end (straight out of Sensible Soccer) that could be accessed by any device on the network. You could log in and start a game, and view the current score in a browser.

When goals were scored, you pressed some sweet arcade style buttons and the server updated the score in real time, as well as playing a couple of ‘goooaaallll!’ sound effects.

What tech / magic / sorcery did you use to make this awesomeness?

We had a node.js server running on the Raspberry pi, listening to button presses on the Raspberry pi GPIO ports, using the node GPIO library, and a custom extension named ‘Pinhead’. The server displayed the scores over the network, which was updated with Socket.io whenever a goal happened. Sounds were triggered both through the raspberry pi’s audio socket, and on the front end.

What were the big gotcha’s?

We ran into a couple of issues getting node to read the (analogue) sensors that were intending to register goals, so we had to emulate that by pressing buttons instead.

The rpi-gpio package was quite limited in detecting changes in the pins (which happens when a goal was scored). We ended up putting together a new npm package which allows users to easily monitor any raspberry pi pins for changes: https://www.npmjs.com/package/pinhead

What’s next?

To implement a live virtual dashboard, we need to send data over to the iPad application with very less latency. 

Attempt 1:

We hosted an HTTP server on the BeagleBone to send data to the application. The app polled for 'new data' every 300ms. Also, every time the connection is establish the http header takes 200ms. This approach is not useful because of this overhead and more importantly the battery gets drained very soon due to constant polling. 

To solve this problem, we needed some mechanism to keep the connection open and asynchronously send data when available. 

Node JS and Socket IO to the rescue: