Hi,
We're currently setting up an application environment where we use the RTI Routing Service to bridge an SHMEM domain to a TCP domain. We're seeing some latency and quirks that we can't quite work out how to resolve, and I hope you can help.
Our setup is the following:
So, there's three entities: A Server, a Client, and a Broker. And we use both Ethernet and WiFi.
The Routing Service is running on the Server as such:
What we're seeing, is three things:
Routing Propagation Delay
We are streaming a lot of data from the Server to clients on the network, and the propagation delay for that data seems to be on the order of one second. This is regardless of whether the clients are on the WiFi, or wired Ethernet. We performed the same streaming test with a wired Ethernet, no Routing Service, and UDP Multicast, and transmission of that same data was virtually instant.
Can it really be true that the Routing Service introduces that kind of delay into the network? If not, what are the (QoS) factors that might affect this delay?
Routing Service Registration Time
Clients connect to both the Server and the Broker. Connection to the Server is over Wifi/LAN, and connection to the Broker is WiFi-only (with no Routing Service). When we start up our client app, it takes ~2 seconds for it to establish a connection with the Routing Service, while registering on the WiFi Multicast service with the Broker is instantaneous. Can we do anothing to optimize the (TCP) connection to the Routing Service?
Domain State Refresh
When we first register a Client with some Routing Service, that Routing Service dilligently forwards the state (samples) that have previously been posted on the inside domain (0) to the Client on the outside domain (1). However, if we disconnect the Client and then re-connect it to the same Routing Service within a short interval, the Routing Service won't forward the state information to the Client again. We realize that the Routing Service probably recognizes the Client as having been present before (or it hasn't noticed that it's been disconnected because it was only for a short time), and thus won't forward state (again). However, we would like to configure a different behavior, where the Routing Service forwards the state every time someone connects, regardless of whether they were recently already connected. Is this possible, and do you have any hints as to where to tweak the QoS to accomplish it?
Any help would be greatly appreciated!
Thanks,
/Franck
Hi Franck,
Routing Service propagation delay
Does the delay affect only to the first sample? or is it to every single sample? If this is the case, Routing Service should not be the problem. One second delay per sample is too high to be a Routing Service propagation issue. Routing Service does not complex processing of the data being forwarded, so the penalty delay is very low, to the order of microseconds. If you are getting one second delay, it seems to me there are other problems potentially related to the network.
Given that you have a not trivial setup I would start to simplify the network/DDS architecture to rule out things. I would check:
Domain state refresh
I'm assuming that disconnecting a Client is equivalent to unplug the network cable while the application process keeps running. If this is the case, what is happening is that the DDS entities GUID remains the same. In this situation, if the liveliness of the entities has not expired, when the client reconnects will not have any effect from the DDS point of view. There are two things that you could do to check this is true:
Let me know your thougths and results on this.
Best,
Antonio