Visual Rx – Part 4
this post is the 4th of the Visual Rx post series.
this post will focus on the communication channel settings.
you can see this series TOC in here.
at the time I’m writing this post there is 4 available communication channel (out of the box).
- Wcf discovery – will try to dynamically locate the end point of the viewer service (or any other discoverable service which apply to the Visual Rx contract).
this is the easiest proxy and it is recommended to local network scenarios.
- Wcf queued – which submit the datum though MSMQ channel (the default viewer is compatible with this channel).
- Trace Source – publish the data though the standard .NET Trace Source. using the "VisualRx" trace source name (for internal messages it use "VisualRx.Log")
the app.config setting will be discuss on latter posts.
- Wcf Fixed Address – is a new one, it is let you specify a Wcf Binding and End-Point (and gives you the full flexibility of the Wcf library).
Visual Rx Viewer side:
at the viewer side you simply dealing with a traditional Wcf application configuration (for setting a Wcf channels).
from version 2.0.20622.10 the default application setting is enabling Wcf discovery over named-pipe and Wcf fixed address over basic http.
other setting like MSMQ and Wcf discovery over TCP is remarked.
you can see the full application setting in here.
but the part that you are rely care about is:
removing the remark from lines 2-4 will enable MSMQ channel (make sure that MSMQ is install on the machine).
lines 6-8 is the Wcf fixed address over http.
lines 10-16 is the Wcf discovery endpoints (the TCP endpoint is remarked).
actually this is all you have to do from a viewer perspective.
Visual Rx Code side
at the code side you should choose which channel proxy do you want to use at the setting initialization of VisualRxSetting.
you can choose multiple channels at once, but you have to make sure that you don’t create a duplication in terms of a viewer will get the same result, from multiple channels, which will lead to duplication of data at the viewer side.
the following snippet is enabling all 3 Wcf channel types:
each channel creation is having a few overloads.
the sample above is using the most simplistic ones.
the Wcf discovery is the most easy channel, because you don’t have to configure a fix address and the proxy will locate the viewer dynamically.
the downside of this channel is that it is limit to a local network boundary and if that network has a vast number of machine the discover process could be slow and heavy.
you can set the timeout for discovery both in the code and the viewer sides.
the viewer setting is take place within the application configuration at the following section:
it is define the maximum time that the viewer will randomly delay its answer (this number has to be lower then the proxy timeout setting which will be discuss in the next section), Wcf is using this setting in order to reduce the network pressure.
at the proxy side you can use the default creation which is using a 3 seconds timeout and retry to discover new viewer at a 30 minutes interval.
but you can pass a VisualRxWcfDiscoverySettings parameter and set those setting manually.
the Wcf discovery proxy will try to locate both named-pipe and TCP end-points (no need to any special setting for that).
Wcf Fixed End-Point
the Wcf fixed end-point is having 3 creation options:
- CreateDefaultHttp is the most simple one and it operate over a basic http binding. all you have to do is to supply the Machine name or IP address of the viewer machine.
- Create is having 2 overloads which is getting any Wcf binding and the end-point address of the viewer. it is very flexible in terms of the binding, it can take advantage of any binding setting (like security, session or even a restful like webHttpBinding).
the Wcf Queued binding is operating over MSMQ and it is having the following overloads:
- the default creation is using a private queue named VisualRx and time to live of 30 minutes (time to live define the period that the message will live in the queue before it will become stale).
- the second overload let you control the time to live setting.
- the 3rd one is let you a full control over the binding.
- and the 4th is also let you control over the queue path.
that all for this post the TraceSource will be discuss in further posts.
communication between your run-time streams and the viewer is fairly flexible and you actually can add your own custom proxy by implementing the IVisualRxProxy interface.