Hi,
I've been using the RTI Connector with nodejs to create a web client that displays DDS data and it has been working well.
One thing I'm not clear about is how it works with multiple clients. Do I need to instantiate a new Connector for each client? If I don't do this, does that mean that all the clients would be using the same DDS entities defined in the configuration file?
Thanks,
Anne Fiore
Hello Anne,
Before answering I would like to better understand what do you mean with 'web client'. Do you have a nodejs script running on a server (using the connector) and a web page connecting to it using the browser through HTTP to that script?
DDS Apps <---> DDS <---> nodeJS Connector <---> HTTP <----> Browser
If that is the case, I would say that no: you don't need a new connector for each client. For example, you can have a reader in the connector and call read instead of take so each client can get the same data. It really depends on what you are trying to achieve though. The connector is just another DDS application.
Would it be possible for you to explain what are you trying to do with more details?
Best,
Gianpiero
Hi Gianpiero,
Thanks for the information. So it sounds like we might need a unique Connector for each client (even if we use read). Here is a little background on what we are trying to do:
We would like to implement a web service using the Connector that behaves as api. We don't intend to serve any HTML pages. The client would authenticate (TBD) and the api would create a web socket and begin pushing data to the client. Clients can also send control information (via the socket) to the server to request additional data. We would use the Connector to write a request to the DDS bus to signal another DDS application to begin sending data. This is what I'm concerned about. If one client requests a different set of data, I don't want to send that data to all the clients. I would like to start the reader for just the client who requested the data.
I hope this makes sense. I'd appreciate any other ideas you have on this.
Thanks,
Anne Fiore
Hello Anne,
From what I understand, your nodejs server, will have two interfaces: on one side it will talk to the clients using websockets. On the other side it will access the DDS databus using the connector.
+--------+ +---------+ +---------+ | | | | | | | C1 | | C2 | | Cn | | | | | | | +---^----+ +--^------+ +-----^---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--------v---------------+ | | | | | +--------> <----------+ | websocket | | | | | +------------------------+ | | | | | | | connector | | | +---------+--------------+ ^ | | | + | <------------------+---------v------------------------> DDS DATA BUS <----------------------------------------------------->As an example, let's assume that C1 wants to know the temperature being published by a DDS app. C1 could send a command through web socket asking to read from temperatureReader. The logic of the nodejs server will call read on the right reader, obtabin a sample (in json) representing the temperature, and the websocket will push that object to C1.
If C2 later wants to have the same information, it will do the same request, and because a read was called before, the information will still be available and ready for the nodejs server to send it to C2 through websocket. Because both Client are really accessing the same datareader cache.
So, i think that the control on which clients gets what information is really a responsability of the 'websocket' side of the nodejs server logic.
I hope this first part make sense to you. As for the 'commands' part - could you give me some example on the requirements of this commands? For instance, what do you need to read, do you need to read what the DR has or do you have to change dinamically the filters and so on.. what are the requirements?
Best
Hi Gianpiero,
I think this makes sense to have the websocket server side handle the information that the client receives.
Most of our application is to stream live data from the DDS bus to the client. We are using transient local durability and history depth of 1 for all our topics so a read will return the most recent sample. We also need to support a request/command from the client to retrieve historical data (up to 12 hours). We don't keep this information on the bus so we are planning that our database application will publish this information when the client request is received. This would just require a read on the 'historical data' topic. We don't have any need to dynamically change filtering, etc.
I've done some more work on the server side to handle multiple clients and I can see that using the same DDS entities across the clients should work.
Thanks for your help.
Anne
Anne,
Great to hear! Let me know if you have any other doubt about the connector!
Best,
Gianpiero