Linked Network Actor--15 on on machine?

[Ben_Phillips]

This is about the Linked Network Actor, a question before I jump right in the deep end.

Sorry in advance for sounding like a punk.  I just get burning questions sometimes and don't have any leisure time...

Are you confident that using LV Network Streams will not collide if you created say 15 actors that had to communicate on the same machine?  All different 15 streams, but all on the same machine/ip.  I've had what I thought were collisions before when using Network Streams.  But it might have been my imagination, I was having other issues at the same time so was wary of pointing a finger.  But I eye them with suspicion now... I just can't see inside there.

I want to use it for a way of isolating out valuable but unstable external code, like an optical isolator.  The other side can go out any time, but you want your main app to remain running.  The only ways I can see to do that are to write my own TCP transmission of all commands and data, and I'm already doing AF, so what the hell let's try this.  DLL's are out, they'll bring down the parent on a crash.  .NET and ActiveX, well too much of a rabbit hole and they might also bring it down for all I know.  I do know, though, that parallel exe's will execute even during a crash.

I do actually trust that the network actor will behave as advertised.  But.  Can it handle 5 to 12 versions all on the same machine?  The intent starting this was apparently talking to another machine, and only one at that (for a RIO machine, RT style (can I get a what what from the RT guys))

I'm wondering if you've tested that.  Because I will get badly burned fingers if I touch this and I'm wrong.  I can do the same thing in TCP in 2-6x the time it would take me to use this and be guaranteed a good time.

I guess I'm asking Stephen or niacs if I should just plow ahead with the TCP route, I think I have this good but I'm a total rookie on this concept.  This one will sting if I choose badly. 

-B$

[CaseyLamers1]

Ben,

I am running around 10 at the same time on a cRIO with no problem.  10 LNAs is really 20 streams because they open 2 connections, one each direction.

Casey

[AristosQueue (NI)]

Nope. I'm not confident about any of it. I've not constructed any real applications with the linked network actors, just a couple of test frameworks. Certainly haven't put together any coherent checking. I'm still waiting for people to say, "Yes, this looks like the right general direction." Very few people have done any work with them and I've got minimal feedback.

I don't know about throughput, scaling, stability, error recovery or target usage. I know that this API works for the basic desktop-to-desktop use case with a stable network. I know of no theoretical reason why it shouldn't work on targets, but I haven't tried it.

Sorry, man, but this one is entirely "I think this is a good idea", but it is still very much "research" and not "development".

Let me know if it works... if it helps your confidence, you wouldn't be the first person to bet a mission critical project on an untested theory of mine. It worked out well the last couple times. 🙂

[AristosQueue (NI)]

BTW... if you want to rip out the guts and replace the network streams with TCP, that would be helpful. See, Network Streams don't work on Mac or Linux, only Windows. I thought Network Streams would be on the other platforms soon, but that turns out not to be the case. There's also the firewall problem -- I can't open a bidirectional connection with network streams through a firewall because both connections have to originate from inside the firewall and Network Streams the communication direction implies the connection direction. So if you make it all work over TCP -- an area where I am woefully unskilled -- that would be an improvement I think. (Of course, you'd lose a lot of the sanity checking and connection management that Streams supply and we'd have to explicitly code that back in, so it might be a bad idea... just sayin'.)

[justACS]

I've wanted a TCP version for a while, but just haven't had the time to write it - I'm actually a bit behind on updates to the existing LNA, for that matter.  If someone does eventually write a TCP version, I would like to explore giving the two a common abstract parent - at that point you could just swap out one for the other with minimal fuss.

I helped Casey set up his application; his is the largest use of the LNA of which I am aware.  He is running that many LNAs, so I see no reason why you couldn't run a few more.  But AQ is correct in that the LNA hasn't been subject to any formal testing within NI, so your mileage may vary.

[AristosQueue (NI)]

niACS wrote:

If someone does eventually write a TCP version, I would like to explore giving the two a common abstract parent - at that point you could just swap out one for the other with minimal fuss.

I wouldn't see the point of trying to create a common parent. You're never going to "swap" one out for the other -- moving from nested to linked or vice versa would completely and fundamentally shift your entire software architecture... you're moving from a system that communicates with an independently running system to one that actively manages the remote system. You're moving from one that is independently and publically messagable by its own hierarchy to one that is scoped only to your network connection, so I would be surprised if any message is significantly reusable between the two architectures. Given how big the other changes are, spending time putting these two very different classes on a common parentage would seem a considerable waste of time to me. Now, if there's a networking API that they can both call into, that's a different story. But I'd share code by containment instead of inheritance.

[David_Staab]

AristosQueue wrote:

Now, if there's a networking API that they can both call into, that's a different story. But I'd share code by containment instead of inheritance.

[Ben_Phillips]

I think I'll go ahead and try this.  If I run into any problems because of Network Streams, changing it over to TCP might make for an interesting exercise.

Stephen, aren't you talking about something different from Allen regarding the common parent?  I took his meaning to be that we could swap between TCP and Network Streams version of LNA, not replacing the core nested AF functions/actor.

Thanks for the replies, it sounds pretty likely that I should be able to do this without collision.  Even if I only got 10 linkages going, I'd be pretty happy with it.  Will keep you posted...

[AristosQueue (NI)]

Ben_Phillips wrote:

Stephen, aren't you talking about something different from Allen regarding the common parent?

I didn't think I was, but wouldn't be the first time I misread something.

Ben_Phillips wrote:

I took his meaning to be that we could swap between TCP and Network Streams version of LNA, not replacing the core nested AF functions/actor.

I wouldn't bother with this. There's no reason to keep both around. I'd pick one and implement it. The networking layer is private implementation details and making the choice a part of the public API is, to me, a very bad thing. If users have a reason to pick between these two, it means that we have a failure of design insofar as one could do one public operation and the other could do another public operation.