Simple TCP Messaging (STM)

[Jack_A.]

Thanks for the additional feedback...I'll take a look at it.

Regarding classes, I agree that they can be a very powerful tool and that STM could benefit from the extensibility of it.  One of our goals with STM is to much sure that it remains as simple and straight forward as possible so that it not considered a 'black box'.  We encourage users to modify it for their own specific applications if necessary just like you have done with optimizations.  I think if we built STM out of classes, it would become a 'black box' to many LabVIEW users.

-Jack

[Marc Blumentritt]

---

Jack A. wrote:

Regarding classes, I agree that they can be a very powerful tool and that STM could benefit from the extensibility of it.  One of our goals with STM is to much sure that it remains as simple and straight forward as possible so that it not considered a 'black box'.  We encourage users to modify it for their own specific applications if necessary just like you have done with optimizations.  I think if we built STM out of classes, it would become a 'black box' to many LabVIEW users.

-Jack

---

You are right regarding the black box. This way STM is much more transparent for most users, since most users have not worked with classes, yet. Still, classes are very nice 😉

Marc

[Christian_L]

Another reason that STM does not use classes is that one of the main targets for STM is LabVIEW Real-Time, which currently does not support LabVIEW classes.

[Marc Blumentritt]

Oh, I didn't know, that LV RT does not support classes. But this support is planned in the (near?) future? (sorry for out of thread question)

Marc

[Evan R.]

I feel like this is the cool kids' post. I really like the STM API! I have a few questions about the design decisions. I am very new to this, so my questions may have already been debated and decided against. If so, I am definitely curious to hear your rationale.

1. a) Does the use of strings for the message type introduce serious potential programmer error which may not even be diagnosed until well until later design stages?

For example let's say I have a message called "GPSTranceiverData", but I make a typo at one spot in my program: "GPSTranscieverData", this may not be caught as an error until well until late-stage testings.

b) Have you considered using a Strict Typedef to define the message name?

2. Each message handler must exist inside the client's or server's case structure. I appreciate that we could use a separate subVI for each handler, but have you considered the use of an OOP design? With OOP the polymorphism inherent would automatically dispatch a command to the appropriate handler.

Cheers,

Evan R.

Message Edited by Christian L on 03-05-2009 09:43 AM

[ssingh1]

I am unable to install stm_1.0.32 on my LV 8.2.1 Version using installer.

Can you please provide the zipped files for download.

[joernheit]

In the STM Read Message (UDP).vi in the inner case where the received udp data is parsed, the error cluster is checked for 'connection timed out' error. Does it make any sense or got I something wrong ?.

Jörn

Message Edited by JohnHighlander on 11-11-2009 06:26 AM

[sdouglas]

I have looked at the newest rev of the STM VIs (as well as several previous versions) and have noticed one significant difference...the use of UDP pinging to serve as the primary means of establishing connections vs. just simply creating and waiting on a listener.  Does this method work better with regard to reestablishing communications in the event of a cable disconnection or are there other advantages?

Scott

[Jack_A.]

Hey Scott -

Using UDP is especially convenient in the situation where you do not know the IP addresses of the systems out there that you want to talk with.  By using UDP, you can broadcast a "who's out there?" message to detect the systems you'll be working with.  They would in turn respond with an IP address that you could open a session with. 

UDP is a lossy connectionless protocol so there isn't the notion of reestablishing a connection.  If the cable is broken, the data would be lost unless you implement some handshaking on top of UDP.

Hope that helps.

-Jack

[sdouglas]

Hi Jack,

Thanks for the reply.  Makes perfect sense.  I am currently using this method, except that the client sends it's own IP address and listening port to the server during the UDP "ping" so that when the server sees the message, it knows who is not connected and the connection parameters.

I also think that this method is improved over the classic create listener and wait in that it doesn't matter which system is started first.  Either system can be rebooted and connection is reestablished without having to boot the systems in the proper order (i.e. RT box running first then host PC).

Best regards,

Scott