Thingworx connection server . how and why ?

[seanccc]

Hi ,

I went through the document "connection server installation and operations guide" , but still couldn't get point of this component ,  my questions are : 

1. Connection server is supposed to be used when there're lots devices,  but why  can it  mitigate the load of Thingworx server ?  by something like aggregating the device requests then resend ?  I didn't find the information in the document 
2. Can I implementation certain custom logic in connection server ? like transform/convert the device data ? 
3. Does the connection server the closest component to the Thingworx server ? 
4. If I use mulitple edge components/techniques to connect device data, including : virtual thing of Java SDK, protocal adapter  tookkit,  EMS and Kepware ,   when the connection server take part in,   should / can have all of these  edge components connected to the connection server and then the connection server's responsible for transfer all of the request to Thingworx and also the reverse transfer ? 

Regards,

Sean

[PaiChung · Accepted solution]

The basics of the connection server is that it takes many connections in from agents/devices but then communicates that to Thingworx over a single connection.

If a Thingworx server in general can maintain 50K concurrent connections (depends on sizing and capacity)

Then let's say with fairly small connection servers that can maintain 10K concurrent connections (tiny servers) you can now scale to 50K * 10K connections. 

However that doesn't mean the Server can handle all the transactions that are happening, this is just for scaling the number of concurrent connections.

As far as transforming at the connection server, I'm not sure, my guess would be no, because of the function that it serves these connection servers are very small and probably won't have additional support to do transformations.

For question 4, I would double check, but I assume yes.

Hope that helps.

[seanccc]

@PaiChung ,

Thank you, now I understand it much better.  

Regards,

Sean