It would be great to be able to connect to the message router as a client via tcp/ip or named pipes so that messages could be re-broadcast in near real-time any plans for this?
Thanks for the suggestion. We had a similar idea for a protocol (tcp server / named pipe server) in the libraries to which the Console could connect. There are currently no concrete plans to add such a protocol (to the libraries or the router) but that’s definitely something that sounds very interesting and we will consider it for a future version.
However, you can already emulate this behavior somewhat by using a standard outgoing tcp/pipe connection in the router to one/multiple Consoles and configure it to automatically reconnect. This is basically a ‘push’ mechanism rather than ‘pull’.
Say, for example, if you have an outgoing route with the following connection string:
With such a route, the router tries to connect to a Console on the same host every 10 seconds. If the Console is open, the log packets are almost immediately displayed in the Console. If the Console is closed instead, the route discards the packets. The overhead of this outgoing route is negligible (as a connection attempt is really fast with the pipe protocol). Things are a bit different if you use tcp and it is recommended to enable asynchronous logging to prevent blocking.
Of course, the push mechanism has the disadvantage that you need to know the Console destinations upfront and configure the router accordingly but in simple cases this solution works very well.
Thanks thats exactly what we did, works great.