Is it possible to run the Routing Service as a Windows service? I need it to be always available (start on system start up) and not easily shut down by a user (not in a comand shell where a user could unintentially kill it).
The Global Leader in DDS. Your Systems working as one.
Hello gandriotakis,
RS as an executable can be added to the startup processes that are launched by Windows, so that it is executed when the user logs in. However I'm not aware if there is any capability to make an executable to run as a service.
In both cases though, process or sevice, a root user can perfectly kill them. For instance, In Windows 7 an user can stop a service by using the sc command : sc stop MyService.
- Antonio
I'd like to add to the information, something about Windows services and Windows applications run by a user: They are in different memory spaces.
If you run RS as a Windows service all DDS between the RS and a user's application(s) will be over UDP loop-back, you won't be able to use a SHMEM transport here.
We have another DDS application that runs as a service successfully using UDP. Running on start up still leaves the artifact of a console window which a user can unintentially kill. I don't think sc will kill an application that is not designed to respond to sc commands. I can use brute force to kill it but that is less than elegant. My thought at this ime is to use svrany to wrap the RS application. Are you aware of any issues with this? Alternatively is there a way to run RS without a user interface (e.g. is there a command option to not display the console window coupled with a shutdown command that can be published by another application?)
Hello Gary,
I hope you were able to use svrany tool to wrap the RS application. Recently I was helping out a customer who had a similar request. I was able to run the RS application as a windows service using the svrany tool. Further this routing service can be monitored and controlled by another application as long as they do not use shared memory transport. I have explained the steps below. You can use it as a reference if you were unsuccessful in your attempt to run the RS as a windows service.
The Routing Service can be run as a Windows Service using the srvany tool available in the Windows Resource Kit. The details on how to create a user defined service using the srvany tool is available in the following Microsoft Support page: http://support.microsoft.com/kb/137890. While adding the Parameters key make sure to use full path names to specify any files as an option.
C:\Program Files (x86)\RTI\RTI_Routing_Service_5.1.0\scripts\rtiroutingservice.bat -cfgFile "C:\Program Files (x86)\RTI\RTI_Routing_Service_5.1.0\sample_cfg.xml" -cfgName defaultBothWays -domainId 5
This newly created service should be listed in the Services application available in Windows Administrative Tools. Here the startup type of the routing service can be set. Further the console window of the routing service can be prevented from interacting with the desktop by unchecking the “Allow service to interact with desktop” option while setting the Log On option to Local System account.
Another point to remember is not to use shared memory transport to facilitate interaction between a windows application run by a user and a windows service as they use different memory spaces. More information about this is available in this Knowledge Base article: https://community.rti.com/kb/why-doesnt-my-rti-connext-application-communicate-rti-connext-application-installed-windows. This means the Connext user applications need to be configured to use UDP transport. The routing service should also set the transport setting of the participants it creates for monitoring and remote administration to use UDP transport. This can be done by setting the participant_qos to use UDP transport within the administration and monitoring tags in the routing service configuration file.
Hello Harish,
I am just getting back to this. I have the following situation:
I have a service application we wrote that communicates with normal user space DDS applications using UDP as required. This works fine.
The routing service working as a normal application using the tcp_transport.xml example as a model works fine.
I then modified participant_1 as follows:
<participant_qos><transport_builtin><mask>UDPv4</mask></transport_builtin><discovery><initial_peers><element>builtin.udpv4:/127.0.0.1</element><element>builtin.udpv4:/192.168.1.193</element></initial_peers></discovery></participant_qos>Hi Gary,
The error could be due to the way intial peers are set. I think you are missing a '/' before the IP address. Could you try the below code:
<discovery>
<initial_peers>
<element>builtin.udpv4://127.0.0.1</element>
<element>builtin.udpv4://192.168.1.193</element>
</initial_peers>
</discovery>
You can also have a look at this article - https://community.rti.com/kb/how-do-i-set-initial-peers-and-multicast-receive-address-programmatically-or-xml
I have this partially working now. I have two PCs on either side of a VPN.
On side one the routing service is running as a Windows service and communicating with a Connext application also running as a service which communicates with a Connext application running in the user space. The communication is routing service <-> connext service <-> connext application.
Side two is running in the same configuration (using the same profile and peer list with the appropriate address modifications).
In this configuration there is a break down such that side two does not communicate with side one.
If on side two, I run the routing service from a command line (and all else the same) everything works fine.
I suspect that there something in the Windows configuration that is causing the problem. Any suggestions?
I think the Windows Firewall might be blocking the data sent from RTI Routing Service when run as a Windows service. Can you try to setup the connection with the firewall turned off? I came across this post in stackoverflow where they were discussing a similar scenario - http://stackoverflow.com/questions/10942916/windows-service-listening-on-socket-while-running-as-localsystem.
The firewall settings appear to be the same of both machines.
What would cause this error:
NDDS_Transport_TCPv4_Plugin_logMessageResponseError:control protocol error response (code=1, string=transport class mismatch)
Can I use shared memory for communication between two RTI applications running as Windows services? Specifically I have a management service that communicates with non-service applications using UDP. If I set up the RTI Routing Service and my application to use shared memory and run both as Windows services will they communicate?
Yes. I think Shared Memory will work if both applications are running as WIndows services. My understanting is that the problem only occurs between talking between an application running as a Windows-Service and another not running as a service. I assume you are already familiar with the explanation we provided here: https://community.rti.com/kb/why-doesnt-my-rti-connext-application-communicate-rti-connext-application-installed-windows
Gerardo
How did you run it as a Windows Service? What version of Windows are you using? It is my understanding that the SvrAny tool in Windows Resource Kit can only be used with older versions of Windows. Windows7 and later require the "service application" to have special code that handles some events from Windows. See for example http://stackoverflow.com/questions/18557325/how-to-create-windows-service-in-c-c). However there are some commercial products that claim they can turn a Windows executable into a service. See http://www.coretechnologies.com/products/AlwaysUp.
We actually do have the event-handling logic to run as a Windows Service in some of our newer producs but as far as I know this is not supported in the current version of Routing Service...
Gerardo
We are using srvany.exe on WIndows 7 and have not noticed any problems. As you note when we move to a later versin of Windows will likely need a different solution.
FYI, we have switched to NSSM as our service wrapper and found it to to be more reliable under Windows 7.
We now have basic communication through the routing service running as a Windows service. We are using it to distribute status periodically for multiple sites across a WAN. If we use a reporting period of 6 seconds normally everything goes fine but we find that at random intervals several reports will be missed. We see the reports on the originator topic but not received by the subscriber. Any ideas as to the source of the instability?
Hi Gary,
Firstly thank you for sharing the information about NSSM.
The default reliability settings of the Connext DDS DataReader is Best Effort. In order to ensure strict reliability you will have to configure the DataWriter and DataReader at each hop to use reliability kind as DDS_RELIABLE_RELIABILITY_QOS and History QoS kind as DDS_KEEP_ALL_HISTORY_QOS. More information about this QoS policy is available at https://community.rti.com/rti-doc/510/ndds.5.1.0/doc/html/api_cpp/structDDS__ReliabilityQosPolicy.html.
The routing service internally uses a DataReader to receive data at one end and a DataWriter at the other end while forwarding data. The QoS settings of these two entities also need to be configured to use Reliable Reliability. These settings can be configured under Domain Route, participant_1 or participant_2 tags. Information regarding this is avaiable in the Routing Service Users Manual, Section 2.4 XML Tags for Configuring Routing Service, 2.4.2 Domain Route Table 2.5.
Hi Harish,
If I am using the TCP transport between the two routing services then shouldn't it naturally be reliable without additional configuration?
The problem seems to be a case of multiple similar and closs together transmissions stepping on each other.
I have been having difficulty specifying reliabe service in the routing service profile. Can you provide an example?
sounds like the so_rcvbuf size is too small to buffer the incoming data long enough for DDS to accept it.
Note the TCPv4.tcp1 may differ depending on your configuration. I also don't know if recv_socket_buffer_size is enabled in the TCP trasport. And the 1048576 is suitable for tuning based on your need.