Routing Messages Through a Hierarchy

[AlexAAuck]

Hi guys,

As part of my project, I have to write a TCP connection actor. So far I've set it up as per the following UML:

My question is:

Is  there an elegant way to route messages through the TCP controller to the TCP sender other than simply writing a 2 stage message? At the moment I have it so that the SendTCPMessage method takes an AF Message object as input, flattens it to string and sends it via TCP. What I'm wondering, is whether I have to write a method in the parent (which I guess could be over-ridden in TCP Sender) which simply routes a "Send Via TCP" message through to "TCP Sender", or whether there's a more elegant way to route between layers?

As an aside for anyone looking at this and thinking, "is this kid an idiot?" Please let me know how I could improve my thinking about the abstraction. The idea is that you either fire up the TCP controller in LaunchState "Sender" or "Listener" (hence the Enum). When a connection is made the controller spins up the other half of the connection. So if it fires up as a listener, and receives a connection, the TCP Listener will notify the controller (have to write this code still) which will store the connection info and then spin up the Sender, and vice versa.

[AlexAAuck]

Further to my previous question (I went ahead and tried to implement what I was talking about).

Is it possible to send exactly the same message object to a parent and child which have a dynamically dispatched method.

So I want to send "Send Message Via TCP" to the controller, it's method (dynamic dispatch) simply routes the exact same message through to the "TCP Sender" child. When it arrives at the child I want it to dispatch to the childs method which implements the flatten to string behaviour. The problem is, as I see it, the "Do.vi" of the message only casts to a single Actor class, either the parent or the child. So I would have to write 2 messages? Is there a way to do what I'm talking about?

[Daklu]

AlexAAuck wrote:

The problem is, as I see it, the "Do.vi" of the message only casts to a single Actor class, either the parent or the child. So I would have to write 2 messages? Is there a way to do what I'm talking about?

If I'm understanding you correctly, yes, you have to write two messages.**  Labview is a "single dispatch" language.  In other words, the dynamic dispatching only looks at a single conpane terminal--the class input--to decide which method to execute.  What you're asking for is a "double dispatch" feature.  Some languages implement it; Labview does not.

**There are ways to simulate multiple dispatch behavior using the visitor pattern, but I have not looked into them extensively.

[drjdpowell]

AlexAAuck wrote:

Is it possible to send exactly the same message object to a parent and child which have a dynamically dispatched method.

This doesn't make any sense.  A class can be a child of another class, but object instances of those classes are different objects and not "related".  So what does this mean?

AlexAAuck wrote:

So I want to send "Send Message Via TCP" to the controller, it's method (dynamic dispatch) simply routes the exact same message through to the "TCP Sender" child. When it arrives at the child I want it to dispatch to the childs method which implements the flatten to string behaviour. The problem is, as I see it, the "Do.vi" of the message only casts to a single Actor class, either the parent or the child. So I would have to write 2 messages? Is there a way to do what I'm talking about?

The way I made a TCP connection with actors was to have a "TCP Listener" actor, which waited for connections from a remote "TCP Client" actor, then spawned a "TCP connection" actor.  There is no parent-child relationship between these processes.  "Send via TCP" messages are sent to the Client, which flattens and sends them via TCP to the Connection actor, who then forwards them to their final destination.

[AlexAAuck]

Interesting, and if you have to send something back the other way through the "TCP Connection" actor, how is that functionality called?

[drjdpowell]

My messaging framework supports self-addressed replies and registering to receive event notifications.  The TCP Connection actor alters the return addresses so that replies/notifications are routed back through it and its TCP connection.  That is how information gets back to the processes that sent the original message via the TCP Client.  My actor relationships are always asymetric in this way; only one actor actually initiates communication and the receiver only replies or publishes information.

[AlexAAuck]

Ok, so your use case sounds a little different to my use case.

Basically, my use case is a distributed UI, the TCP Server sits on an RT machine and waits for connection. When connection is made, it receives commands about what experiments to do, and then returns the information to the UI on the windows machine. Quite a lot of information is sent through the connection (image stream), I envision it more like the UI opening up a pipe from the RT machine and then acting more like a listener that sends occasional commands to change the measurement.

So, basically, the event notification model doesn't make sense (at least to me), and neither do self addressed replies (to me I imagine "send me a picture" repeated ad nauseum at high speed).

So what I imagine is a client that connects, then spins up a "TCP Listener" pipe which feeds directly to the UI (I envision the TCP Client and TCP Listener being thin wrappers which basically shuttle AF Messages back and forth from RT controller to UI). So I need bi-directional communication but the spin up operations are different depending on where you start. I suppose I don't really need a controller at all... I could just have Listener and Client. Listener spins up Client and vice versa? Hmmmm.

Edit: Further to that thought, I actually would want three actors, like you do, I was conflating the actions of a Listener FOR connections and a Listener TO a connection.

[drjdpowell]

AlexAAuck wrote:

Basically, my use case is a distributed UI, the TCP Server sits on an RT machine and waits for connection. When connection is made, it receives commands about what experiments to do, and then returns the information to the UI on the windows machine.

...

So, basically, the event notification model doesn't make sense (at least to me)

Actually, that basically is the use case I intended.  The UI connects, sends commands, and registers to receive the information it requires. 

Although, if I needed very high throughput such as video, I might use the messaging system to send commands to set up a dedicated, special-purpose connection, avoiding any overhead of packaging things in messages and passing them through multiple actors.  Low-throughput stuff, status and commands, would still go through the messaging system.