Simple TCP Messaging (STM)

[Danny_L]

There seems to be an issue when using "Write Message (TCP).vi with a timeout under unusual conditions.

"Write Message (TCP).vi" doesn't correctly handle the case where "TCP Write.vi" byte written is less than the size of data in. This lead to a corrupted STM stream that the client can't handle.

This is succeptible to happen if the transmit buffer of the server becomes full.

This doesn't seem to happen when the timeout pass to "Write Message (TCP).vi" is -1 (wait indefinitely). I don't know if it will possible to fix while keeping the "timeout" functionality wihout support from the TCP layer.

I have been able to reproduce this running a client under windows and running the server on a CRIO-9068 and a CRIO-9075. Test case attached.

Regards,

Danny

[Staab_Engineering]

Bug Report 1

(This might be related to Danny_L's bug report above.)

I think "Read Messsage (TCP).vi" uses the wrong "mode" parameter when it calls the TCP Read primitive. It allows the default value of "standard", but that value pops bytes from the buffer if all 4 expected bytes fail to arrive before "timeout". It seems like "buffered" mode should be used, so bytes stay in the buffer if fewer than 4 become available. Popping a partial message/header from the buffer seems like it might corrupt the stream.

---

Bug Report 2

The "timeout" parameter is implemented incorrectly on "Read Message (TCP).vi" and "Read Meta Data (TCP Clst).vi".

• In the former, the parameter is connected to both TCP Read primitives without accounting for spent time on the first prim. This risks spending as much as [timeout * 2] ms waiting for the VI to execute. An appropriate implementation should track the time spent executing the first prim and subtract that from "timeout", passing the result as a parameter to the second prim.
• In the latter, the "timeout" parameter isn't connected to the second TCP Read prim. In an error situation, this risks hanging the thread until an unknown number of bytes arrives at the port.

---

Bug Report 3

"Write Message (TCP).vi" doesn't use the "ignore timeout error" parameter on its connector pane.

[David_Staab]

Is there a .NET assembly for STM?

[Brian_K.]

The closest I think we have is http://www.ni.com/example/31208/en/.  Man I created that a long time ago.  From what I can remember the TCP stuff was actually pretty trivial.  Flattening/unflattening took me forever to figure out, so at the very least hopefully that helps. 

[smithd]

Hey Danny and Staab,

We've moved the STM codebase over to github here https://github.com/NISystemsEngineering/STMMessaging/ and the issues you've listed are Issue 1, Issue 2, and Issue 3. If you come across any other issues please feel free to add them to the tracker (and let me know if you don't have permissions to do that for whatever reason).

In addition, since it is github you are welcome to fork the code and make any changes you see fit. There are a few guides on ni.com/referencedesigns and plenty more on the web if you decide you're interested in contributing.

Thanks,

Daniel

[Danny_L]

Thanks Daniel.

Quick question : Is this only to share LabVIEW code or code in other languages are also permitted / allowed?

For example, It might be interesting to have provision to share .Net, C, C++ or other language implementation of STM and Flatten To/Unflatten from string.

Regards,

Danny

[smithd]

Hey Danny,

Any language would be fine. I was considering moving the C wrapper described above over but I didn't think of it until after I had left work.

If you did have some code you were interested in contributing at a later date, the process (broadly speaking) goes like this:

-Create a github account

-"Fork" the STM repository I linked (big button, top right)

-Make your changes either in the main code ("Master" branch) or make a new branch to contain the changes

-Submit a "pull request" to the STM repository I linked, which alerts us that you've made some changes you want to incorporate.

Thanks,

Daniel

[David_Staab]

Hi dsmith-

The NI Sample Code License seems brutally unilateral to me, so I've decided not to contribute to NI's public projects unless I'm getting paid for it. If you guys ever decide to enter the open-source community with actually open (copyleft or at least permissive) licensing, I'll be happy to lend my time to the cause.

[smithd]

In case anyone comes across this thread, the above issue^ was resolved. 

The intent for (almost?) all of our code on github is that the source is licensed under bsd while the NI-built distribution (VIP) which we (NI) put on tools network, or ni.com/referencedesigns, would be licensed under the sample code license.

[Scott_Campbell]

we have multiple hosts communicating to Crio both Ethernet and wireless. if a connection is lost the Crio gets timeout error 53 this does not cause the Check connection.vi to Close the connection. close connection case handles 1,62, 64, 66. Timeout error code 56 needs to be added. we have done this and it solved issues with reconnection, it would be nice to see this in the offical version.

Scott Campbell