cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

Which protocol is used by thingworx to communicate with KEPServerEx

SG_10718850
5-Regular Member

Which protocol is used by thingworx to communicate with KEPServerEx

I want to know which protocol is used by thingworx to communicate with KEPServerEx and why only that protocol why not other? If you have a link of a documentation related to this please share with me.

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Hi @SG_10718850 

That post only offers only half of the answer, because you are also asking "why only that protocol and why not other".

In short, you are not going to find an official description of why we have chosen this protocol, but overall I can tell you its advantages (assuming you've already read the post).

AlwaysOn is a proprietary PTC protocol, that is used by all PTC IIoT components when they interact with each other. If you know MQTT, at a low level it can be seen as similar to MQTT (because it opens a TCP connection that then it keeps open through keepalive messages), but after that it has a bunch of other capabilities outside of the MQTT realm. To recap, MQTT only works with messages (that it publishes, or receives if it subscribed to a topic).

AlwaysOn on the other hand, uses internally a REST-style communication structure, where it basically sends messages to a specific end-point (same end-point being always available also via REST to other clients). These end-points I speak are existing ThingWorx platform end-points, and since AlwaysOn existed since ~8-9 years, whenever you need a specific high-speed interaction with the platform, you always use AlwaysOn.

More important, AlwaysOn includes a binding mechanism, through which VirtualThings (client-side things) bind themselves to RemoteThings (server-side things), which then allow receiving property values, execution of remote services triggered from server, remote file transfer if needed.

Since we have a couple SDKs (also available for customer use), whenever you need high-speed data or fast time to act , Always-On is the logical choice, since all our EdgeSDKs (including what we used in Kepware) abstract the operations you need to do very nicely behind different high-level services.

Another very important thing is bandwidth. MQTT would use, as it is configured today in Kepware, ~30-40% more bandwidth, which, in industrial scenarios, is not exactly something you would want. Serializing the message using stuff like Thrift/Protobuff probably would reduce this bandwidth, but then it would complicate consuming that data on the client side.

 

So, overall, it's just the logical choice for ThingWorx, considering the available SDKs for AlwaysOn we have.

 

View solution in original post

2 REPLIES 2

Some old discussion - "Protocol between Kepserver on edge device and Thingworx on cloud": https://community.ptc.com/t5/Kepware/Protocol-between-Kepserver-on-edge-device-and-Thingworx-on-cloud/td-p/697351

Hi @SG_10718850 

That post only offers only half of the answer, because you are also asking "why only that protocol and why not other".

In short, you are not going to find an official description of why we have chosen this protocol, but overall I can tell you its advantages (assuming you've already read the post).

AlwaysOn is a proprietary PTC protocol, that is used by all PTC IIoT components when they interact with each other. If you know MQTT, at a low level it can be seen as similar to MQTT (because it opens a TCP connection that then it keeps open through keepalive messages), but after that it has a bunch of other capabilities outside of the MQTT realm. To recap, MQTT only works with messages (that it publishes, or receives if it subscribed to a topic).

AlwaysOn on the other hand, uses internally a REST-style communication structure, where it basically sends messages to a specific end-point (same end-point being always available also via REST to other clients). These end-points I speak are existing ThingWorx platform end-points, and since AlwaysOn existed since ~8-9 years, whenever you need a specific high-speed interaction with the platform, you always use AlwaysOn.

More important, AlwaysOn includes a binding mechanism, through which VirtualThings (client-side things) bind themselves to RemoteThings (server-side things), which then allow receiving property values, execution of remote services triggered from server, remote file transfer if needed.

Since we have a couple SDKs (also available for customer use), whenever you need high-speed data or fast time to act , Always-On is the logical choice, since all our EdgeSDKs (including what we used in Kepware) abstract the operations you need to do very nicely behind different high-level services.

Another very important thing is bandwidth. MQTT would use, as it is configured today in Kepware, ~30-40% more bandwidth, which, in industrial scenarios, is not exactly something you would want. Serializing the message using stuff like Thrift/Protobuff probably would reduce this bandwidth, but then it would complicate consuming that data on the client side.

 

So, overall, it's just the logical choice for ThingWorx, considering the available SDKs for AlwaysOn we have.

 

Top Tags