How to track child instances in parent class

[nathand]

---

LabVU_Dog wrote:

However, all good parents are able to keep track of their children. The TCP class needs to be able to track all active ODS instances on that TCP connection. We are struggling with the best method to use for the TCP class to keep track of all ODSs. Adding an array of ODS class instances to the TCP "private data" does not work, due to circular referencing between parent and child classes.

---

You are confusing inheritance and composition. A good parent class doesn't know anything at all about its children. If you want an instance of the TCP class to know about every single connection, then you should be using composition, not inheritance. Otherwise, since every child is an instance of the parent class, in your implementation you want every instance of the child to know about all of its siblings. What it sounds like you should do instead is split the functionality, perhaps a TCP class with children, and a TCP Manager class that tracks all of the instances.

Of course, as drjdpowell points out, TCP guarantees that messages will be delivered in order, so there's probably a way to to dramatically simplify your design.

[LabVU_Dog]

It's interesting that you say that the order delivery problem has been fixed in TCP. I was unaware of that, and have been using some form of stream ordering since the late 90s when it was a trivial ordeal to demonstrate the TCP ordering failure.

I will have to investigate that further to determine if the current implementation of TCP in LV resolves the ordering issue.

[nathand]

---

@LabVU_Dog wrote:

It's interesting that you say that the order delivery problem has been fixed in TCP. I was unaware of that, and have been using some form of stream ordering since the late 90s when it was a trivial ordeal to demonstrate the TCP ordering failure.

I will have to investigate that further to determine if the current implementation of TCP in LV resolves the ordering issue.

---

Maybe you're confusing TCP and UDP? Correct delivery order is part of the TCP protocol (and, as far as I know, always has been). LabVIEW doesn't implement TCP at all - it just provides wrappers around operating system functions. If TCP didn't guarantee delivery order, the internet pretty much wouldn't work. All the protocols built on top of TCP - HTTP, telnet, etc - would routinely fail since they all rely on the TCP stack to deliver every packet in the correct order.

[Intaris]

Are you using multiple TCP streams in parallel?  If not, ordering should NOT be a problem.  Make sure you're using TCP and not UDP.

TCP AFAIK guarantees the order ot transmission.

Shane.

[GabbyG]

Hi

I do most of my classes in G#.

They have not only a Data field for the instances(attribute) but also a common data field for the whole of the class(class attribute).

I used that once to have each instance (Yes they also have a create/destroy default method)  register with the class.

Although I am not sure how this is handled during inheritance.

Gabi 

[drjdpowell]

TCP is a stream; the IP packets don't correspond to "messages", so if the ordering is lost then the messages are hopelessly scrambled.  Order failure would thus be a major bug in TCP.  In contrast, UDP has "datagram" packets containing one message each, allowing them to arrive uncorrupted but possibly in the wrong order (or be lost completely if "resend" logic isn't added on top).

[LabVU_Dog]

I am sure that I'm using TCP. I use UDP for other things.. it's a totally different tool.

I don't remember exactly when, but it was some years ago that we demonstrated convincingly that TCP did not guarantee the ordering of messages (at least in LV). Perhaps this was in LabVIEW version 6.0, which had all those TCP bugs? It was almost unusable for TCP. Anyway, we contacted NI, and I think talked to several experts at NI Week, and it was fairly well known at that point. I have been addressing message ordering as a user concern since then.

It would be wonderful to not support this functionality in user space. I'll do some testing. Thanks for the heads-up!!

[LabVU_Dog]

NI tech support confirms that TCP does not guarantee message ordering with TCP. See email snippet below.

By message, I mean specifically the "data in" input to the TCP Write primitive in LabVIEW, for a single call. The contents of "data in" may or may not be broken down into smaller packets for transport across the physical layer. TCP guarantees the "intactness" of each message, but not the ordering of 1 message relative to another. Generally, it will be consistent. But, in cases with other network traffic creating the potential for collisions, the user (app level) must ensure message ordering.

<email snippet>

Hi Derek,

You are correct, the message order can not be guaranteed.  For non-critical applications, I would say that since your system is separate from the ethernet, we could assume that the packets will take the same route everytime, but that can not be guaranteed.  A critical system is going to need some more logic to ENSURE that packets aren't necessarily received in the correct order but processed in the correct order.  I wouldn't be able to speculate on how often this happens, but for critical systems, I would not depend on that order.

Regards

XXX
Applications Engineer
National Instruments
http://www.ni.com/support

------------------------------------------------------------------------------
Hi XXX,
 
Thanks for your thoughts. I use the TCP tools to communicate among computers and realtime controllers (mostly cRIO) on a hardware network. We have a variety of switches in our network, as it extends all across a facility. It is isolated from the internet. I have to be absolutely sure that the high-speed data that I acquire with NI 9237 modules does not get out of order in transit from the cRIO to the computer host.
 
I am hearing from you that TCP does not guarantee the message order (same as sent) on the receiving end. Is that right?
 
Derek

<end snippet>

So now I am back to my original problem.

I'd like to create an ODS child class of the TCP CNXN class. As noted above, there is some confusion in terminology. Any good parent would know all of it's children. It seems the analogy of OO to parent/child breaks down here. I agree with the sentiment that the parent class should have very limited (or none) knowledge about the child(ren). I would also like the TCP class to not be able to do anything with the child class; use only ODS methods for that. But, my TCP class needs to be able to "globally" access all active instances of ODS (for the specified connection). For example, if the TCP CNXN is about to close, all open ODS must also be closed. I **think** the best plan would be for the TCP class to somehow keep track of all ODS active instances, but reserve all ODS actions to ODS methods.

Any design ideas?

I didn't have good luck with the grandparent class idea. It created TCP operations that could not compile, NOR LIST ANY REASON FOR NOT COMPILING!! It simply indicated "VI failed to compile."

I'm working on the variant idea now, that seems to have the most initial success.

[drjdpowell]

The NI engineer is mistaken.  See RFC 793 part 2.6 "Reliable Communication":

"A stream of data sent on a TCP connection is delivered reliably and in order at the destination."

That applies to the entire stream of data, not just to individuals calls on the TCP Send function.  TCP doesn't have any concept of "messages"; it's a byte stream.  

[nathand]

---

@LabVU_Dog wrote:

NI tech support confirms that TCP does not guarantee message ordering with TCP. See email snippet below.

---

NO! This is completely, utterly wrong (and very, very disappointing that an NI tech support person would write this).

As drjdpowell wrote, TCP is a STREAM. You can read any number of bytes from it, and the number that you read doesn't need to match the number that you wrote. The operating system might combine multiple writes into a single transmit packet, or split a long message into multiple packets - but you don't have to care or worry about any of that. TCP guarantees that the bytes will be received by your application in the order in which they were sent. If it didn't, the whole stream concept couldn't work. If by some chance individual packets don't arrive in the correct order, the operating system's TCP stack will correctly sort them out (by reordering or forcing a retransmit) before handing them to your application.

If you still do not believe this, look at the TCP protocol specification, which has been around for over 30 years. Each TCP packet includes a sequence number. The receiving side checks that packets are received in order, with no duplicates and no missing packets. There is no reason to add another layer, duplicating that functionality.