Indicio’s new open-source tool enables websockets to quickly manage large scale mediation without dropping messages
By Colton Watkins
Imagine the following scenario. It’s a Friday morning, the first day of a convention that only comes around once a year, and you’re extremely excited about attending. It’s one of the few yearly events that you’re willing to ask your boss for time off to attend. This year, the convention happens to be using a digital ticket system built on the new Aries Framework technology, and they’ve issued a virtual ticket to a mobile app on your phone. Because the technology is so new, you chose the app that the convention’s website recommended you download.
The new ticket system is supposed to make the entire process of checking in and getting your badge quicker and more convenient than ever before. There’s no need to rush to be early as the lines should be pretty short. Getting ready for the day ahead, you grab your phone, leave your hotel room, and head to the convention center.
The Problem
A short walk later, you make it to the convention center only to be greeted with slow moving lines. This new technology is supposed to be faster, so why are the lines moving as slow as or slower than the previous system?
Turns out, you weren’t the only one who went with the first phone app recommended to you on the convention’s website. Most everyone chose to do the same and, upon checking-in, the convention staff encountered issues retrieving the tickets from each person’s phone. The massive amount of people trying to enter the convention at the same time have overloaded the Mediator the app on their phone was using.
A Mediator is a service that allows software agents (such as those issuing or verifying credentials) to contact other agents that may not have a static IP address—such as mobile devices—or that may be behind a firewall.
The overloaded Mediator leaves the convention center struggling to communicate with conference attendee’s mobile wallets.
Introducing SocketDock
SocketDock is a new tool service created by Indicio that we’ve donated to the open-source community via the Hyperledger Foundation. In the world of fast and responsive technology, websockets are the go-to solution for quick and snappy applications; however, using websockets means that an online service needs to be able to maintain a continuous connection with the user’s application. Depending on the server architecture, this could spell bad news when it comes to creating clustered applications. A clustered application is when more than one server is used to service many more users than a single server can service on their own. In practice, there are many different ways to handle this.
In our scenario, if the mediation were to be clustered out to distribute the load, performance would increase and the slowdowns would disappear; however, we would then encounter an issue with missed messages. When the convention center asks you for your ticket, its system would send the request to one of the clustered mediators for your ticket information. But unless it talks to the same computer system that your phone happens to be connected to, the Mediator would have no idea where to send the message and it would be forced to store it for later retrieval — resulting in your phone needing to manually request the messages from the mediator. This is not a great user experience.
How can SocketDock Help?
When Mediators are running on multiple servers, messages to mobile agents need to be sent to the mediator server that the mobile agent is directly connected to. To get around this, we need to separate the websocket server from the Mediator’s application server. Doing so allows mediators to instantly forward messages to mobile agents without concern for which server an agent is connected to. That’s exactly what SocketDock was made to do. SocketDock can sit behind a load balancer, forwarding any messages that it receives to a mediation system (or any system that runs an HTTP/S server). When a message is forwarded to the mediator, extra information is included in the request informing the mediator as to where it can send replies to.
Now the convention staff can request your ticket from the mediator and the mediator doesn’t need to have an active connection to the mobile wallet. All it needs to know is which instance of SocketDock to send a message to, bringing back the speed and snappiness to the application and providing the user with a better experience. The lines leading to the convention center’s check-in stations should be moving a lot faster now that the mediator isn’t overloaded.
Image by Micah Peltier
Where can I get SocketDock?
All of this sounds fine and dandy, but it’s not very useful unless it can be deployed in front of a clustered mediator system. Fortunately, all of the code is open-sourced over on GitHub in the Hyperledger organization, which you can find here: https://github.com/hyperledger/aries-socketdock
How can I get involved
If you’re looking to learn more about SocketDock, or how you can help out, there are multiple ways to get involved. You can do so by joining the discord or the weekly User Group/Working Group meetings. Links to both of these are on the Hyperledger website.
https://www.hyperledger.org/projects/aries
Another way to help out is by submitting any issues that you may find or submitting pull requests to contribute fixes over at the SocketDock repository. While it may not seem like it, users of the technology can have a larger impact than they realize, so don’t be afraid to lend a hand.
And if you have questions about implementing your own full decentralized solution don’t hesitate to reach out to the team at Indicio.
