Leaderboard

Mainly load balancing and performance. The performance is dictated by the computers resources rather than the dispatcher. With the filtered method you have a congestion point that affects ALL "Topics" and gets worse by a factor of subscribers x topics as you add more topics. Lets say (for example) you are sending 100MB of data on 1 topic which takes (say 10 ms) to transmit to 1 subscriber (we'll ignore filtering overhead). The Dispatcher is able to service all subscribers to that topic every 10ms. If we now add a subscriber to that topic. The time to service all subscribers is now 20 ms. 3 subscribers...30 and so-on. Now we add another topic that also takes 10ms to tx 100MB of data to 3 more subscribers (keep the maths easy). The time now required to service all 6 subscribers on both topics is now 60 ms. 3 Topics, 90ms....... However. with the service handler, each service handler is only handling 3 subscribers so in our theoretical example, each handler is servicing all 3 of the subscribers every 30 ms still. Increasing the number of topics doesn't change the time to service all clients. So whereas before the time to service all subscribers was a compound of the number of subscribers AND topics. Now it is only the number of subscribers. Additionally, whilst the dispatcher is servicing the clients, it is effectively "deaf" to incoming connections which also gets worse as you increase topics and subscribers. Having the dispatcher only handle connections means that this "deaf" time is not dependent on the number of subs/pubs. You can use a queue as, I have, and build a list of connection request but you then have to consider the trade off between handling data or handling a connection request. With significant network lag you can get halts in the data whilst the dispatcher is creating a connection. In my example, the Dispatcher only handles connections (its very responsive to connection requests). Therefore the dispatcher can take as long as is necessary without interrupting the data streams.

Name: Dispatcher Submitter: ShaunR Submitted: 07 Sep 2010 File Updated: 03 Jan 2011 Category: Remote Control, Monitoring and the Internet LabVIEW Version: 2009 License Type: Other (included with download) This is a Publisher/Subscriber implementation of network communications. The package is comprised of two main parts. 1. A Dispatcher that handles connection requests. 2. An API for interacting with the Dispatcher. Overview. Most people are probably familiar with RSS feeds. An RSS feed is an example of a publisher/subscriber implementation, where information is "published" onto the internet and people may "subscribe" to updates using their browser or some other client. A single published service may have millions on subscribers and publish its data every few hours as data changes or periodically, maybe once or twice a day. This package contains a similar implementation where a client "subscribes" to a "publisher", however, it is geared towards high bandwidth data streaming across a local network. So, unlike its internet counterpart, it is not attempting to service millions of clients who require an update once or twice a day. But service a few (maybe 1-10) clients every few seconds or even milliseconds. Detail: The main focus of this package is the Dispatcher which facilitates the publisher/subscriber environment. The implementation can support many network topologies that suit the developers requirements. For example: A single dispatcher may be located on a remote machine and all publishers and subscribers are remote and communicate through it (centralised). Alternatively, there may be many dispatchers on different machines, each with their own cluster of local services and the subscriber connects to the machine that contains the publisher of interest (decentralised). Or even a mixture of both. The implementation is not rigid and allows for the developer to choose the topology simply by installing once or more dispatchers and initiating a connection. An API is provided to enable interaction with the Dispatcher to query its services, request a connection and send/receive data. Additional Features: Supports data-stream encryption (blowfish). Installation: Unzip to a directory of your choice. Required Packages: Labview 9.0 or greater. Transport.lvlib (Included) Queue.vi (Included) Position Form.vi (Included) Stop.vi (Included) Elapsed Time.vi (Included) Known Issues. None. Versioning: Current version 1.0. See changelog.txt. Contact: PM ShaunR on lavag.org (http://www.lavag.org) Click here to download this file

When working with dynamic code, sometimes we end up with a generic reference that we need to cast to complete our operation. Example: You make a sub-VI that extracts the plot color of a waveform chart or a graph. The reference input to that VI must be of a common reference type (GraphChart) The problem is that this property, although it exists for both types of references does not exist in the common type. Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/d223f6b4-83a2-43dd-a830-be17877c9715/2010-09-10_1849.mp4 So if you want to have a piece of code that can operate on both types of references, what do you do? Somehow you need to have a switch in your code that will conditionally run the correct code based upon the specific reference you wire in. The way some people do this is by utilizing the 'Class Name' property into a case structure but this has problems w/ flexibility Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/9f771182-303a-40d2-96db-3701ee43ff7f/2010-09-10_1903.mp4 This is a simple case where there is only 1 or 2 sub-types. What about a numeric w/ all of it's myriad of sub types (slider, guage, etc). The appropriate way to handle this is by doing a type cast, but people typically solve the 'Many Cast' design pattern VERY POORLY through nested error structures. Which looks really ugly Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/7c0e0bfe-966a-458a-8bc8-c44bf6a91cc5/2010-09-10_1913.mp4 So what is our alternative? Introducing the very useful, and practically perfect in every way 'Many Cast' design pattern. It's stackable It's scalable And it even tosses errors properly Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/55e8e391-bb10-4cc2-9a15-2e2a46912bb6/2010-09-10_1933.mp4 The Code is attached, not as a package 'yet' Demo to Follow in the subsequent post Design Pattern - ManyCast.vi

Let me guess: Basic Object Flags? Did you get any "insane objects" when closing the VI before you stumbled on the right bits?