JNIOR Protocols

The JNIOR is a network appliance capable of accepting connections that can monitor and control it. There are several built-in ways to connect to the JNIOR. Each method has its benefits, drawbacks, and use cases.

A brief history and why each protocol was implemented

JNIOR Protocol

The JNIOR Protocol was the first protocol that was developed. It was originally developed for the Series 3 JNIOR. It is a binary protocol. Binary protocols are much faster than ASCII protocols. The Series 3 did not have a lot of processing speed so a binary protocol was needed. This comes with a cost of implementation complexity. The JNIOR Protocol was used in all of our interface applications. This was key in the functionality of the Main Applet, the main user interface for configuring and controlling the Series 3 JNIOR.

WebSockets

There was some noise that the web browsers like Chrome, Firefox, and IE were starting to consider Java Applets to be a security risk. The browsers were allowing a fully functional application to run within them with little ability to control what those applications were able to do. This caused us to start looking into replacing the Main Applet with a native HTML-based user interface. We still desired that the interface would feel real-time. We looked into AJAX, asynchronous JavaScript, and XML, calls to get the status. This meant that the web page had to poll the JNIOR for status updates. This is highly undesirable as it presents increased traffic, and overhead and is slow.

Luckily we saw that a new real-time, bidirectional communications channel was being developed. This was to be WebSockets. WebSockets takes an HTTP connection with a web server and upgrades it to be a persistent connection. Since WebSockets are implemented in JavaScript, this became a perfect fit for a new user interface.

WebSockets represent the connection between the browser and the server. What kind of data that would be exchanged needed to be defined. A protocol format that was tightly integrated into JavaScript had gained a lot of traction and would become the new data exchange format for the JNIOR. That format is JSON.

JMP

WebSockets are great, but the implantation of RAW web sockets presented a little bit of a challenge for non-web applications. While the data exchange format is JSON, it needs to be encapsulated in a Web Socket framing message. This allows messages to be broken into multiple frames just like TCP can break messages into multiple packets.

We knew that we wanted to create a new protocol or channel that JSON could be sent over but with a much less complex framing structure. Other devices and applications were exchanging JSON but we saw an issue with that. How do you know when a complete JSON message has been received? You have to count the open and closed brackets. Seems easy but keep in mind that we need to ignore brackets that are contained in strings that are within quotes. This isn’t complex, it is just overhead. That is when we came up with the simplified bracket length value structure. Basically, this represents a two-position array, a length, and a value. This became JMP or the JSON Messaging Protocol.

So how do you know which option to choose?

For new applications, we do not recommend the JNIOR Protocol. It has been deprecated. There are not any new features being added to it.

When it comes to deciding between WebSockets and JMP the question is not about the type of data being sent since they both use the same JSON messages. Do you have access to built-in WebSockets or a WebSocket library? If you do then WebSockets might be the better choice. If you are implementing the stream yourself then JMP offers a much simpler solution. But WebSockets also carries two additional benefits. One, it uses a well-known port. WebSockets use the web server port. The JNIORs web server port may already be available publicly if the port forwarding was configured. The other benefit is that it can be upgraded to use wss:// over https://.

There may be other things to consider when choosing between protocols. Maybe you don’t want to code the implementation but use a currently available solution from INTEG. INTEG offers libraries in a variety of popular languages. Different connection types have been implemented in different languages. This chart illustrates which connection types are available in the different languages.

INTEG has also implemented the protocols in other languages for customers on an as-needed basis but we have not maintained that codebase.

Another consideration might be what features are available in the protocol. As mentioned earlier, new features are not being added to the JNIOR protocol. This means that features like reading or writing a file have not been implemented and most likely will not be implemented.

Different types of calls in a library

Constructors

Constructors are used to define an object. In this case, they will be used to define the connection.

Callbacks, Handlers, and Listeners

They are all the same. They represent code that is executed when a specific event happens. Sometimes you have a handler that should be alerted any time an event happens, like when IO changes, and sometimes you might only want specific code to be used once, like when a file has been downloaded.