Visual Rx – Part 4

2012/08/15

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.

Profile, Rx, Diagnostic, Contrib, Marble, Bnaya, Dubug, Trace, Visual Rx, IObservable, IObserver, ISubject, Monitor, Monitoring

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:

Code Snippet
  1. <!– used by VisualRxWcfQueuedProxy –>
  2. <!–<endpoint address="net.msmq://localhost/private/VisualRx" binding="netMsmqBinding"
  3.           bindingConfiguration="netMsmq"
  4.           contract="System.Reactive.Contrib.Monitoring.Contracts.IVisualRxServiceAdapter" />–>
  5. <!– used by VisualRxWcfFixedAddressProxy –>
  6. <endpoint address="VisualRx" binding="basicHttpBinding"
  7.           contract="System.Reactive.Contrib.Monitoring.Contracts.IVisualRxServiceAdapter" />
  8.  
  9. <!– used by VisualRxWcfDiscoveryProxy –>
  10. <!–<endpoint name="tcpMonitor" address="Monitor"
  11.           binding="netTcpBinding"
  12.           contract="System.Reactive.Contrib.Monitoring.Contracts.IVisualRxServiceAdapter"/>–>
  13. <!– used by VisualRxWcfDiscoveryProxy –>
  14. <endpoint name="namepipeMonitor" address="Monitor"
  15.           binding="netNamedPipeBinding"
  16.           contract="System.Reactive.Contrib.Monitoring.Contracts.IVisualRxServiceAdapter"/>

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:

Code Snippet
  1. Task<VisualRxInitResult> info = VisualRxSettings.Initialize(
  2.     VisualRxWcfDiscoveryProxy.Create(),
  3.     VisualRxWcfFixedAddressProxy.CreateDefaultHttp(Environment.MachineName),
  4.     VisualRxWcfQueuedProxy.Create());

each channel creation is having a few overloads.
the sample above is using the most simplistic ones.

Wcf Discovery

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:

Code Snippet
  1.  
  2.   <standardEndpoints>
  3.     <udpDiscoveryEndpoint>
  4.       <!– modify the udpDiscoveryEndpoint –>
  5.       <standardEndpoint name="adhocDiscoveryEndpointConfiguration" maxResponseDelay="00:00:00.001"/>
  6.     </udpDiscoveryEndpoint>
  7.   </standardEndpoints>
  8. </system.serviceModel>

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.

Code Snippet
  1. var setting = new VisualRxWcfDiscoverySettings
  2. {
  3.      DiscoveryTimeoutSeconds = 2,
  4.      RediscoverIntervalMinutes = 15
  5. };
  6. VisualRxSettings.CollectMachineInfo = true;
  7. Task<VisualRxInitResult> info = VisualRxSettings.Initialize(
  8.      VisualRxWcfDiscoveryProxy.Create(setting));

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:

Code Snippet
  1. VisualRxWcfFixedAddressProxy CreateDefaultHttp(string host);
  2. VisualRxWcfFixedAddressProxy Create(Binding binding, string uri);
  3. VisualRxWcfFixedAddressProxy Create(Binding binding, EndpointAddress endpoint);

  • 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).
MSMQ

the Wcf Queued binding is operating over MSMQ and it is having the following overloads:

Code Snippet
  1. VisualRxWcfQueuedProxy Create();
  2. VisualRxWcfQueuedProxy Create(TimeSpan timeToLive);
  3. VisualRxWcfQueuedProxy Create(NetMsmqBinding binding);
  4. VisualRxWcfQueuedProxy Create(NetMsmqBinding binding, string queuePath);

  • 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.

Summary

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.

Shout it kick it on DotNetKicks.com

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>