Simple TCP server example fails differently on cable pull

[danniwithNI]

Hi nanocyte,

I wouldn't expect the modifications you made to affect the TCP communication between the devices, but I'm still having trouble seeing the same magnitude of lost samples that you've logged in your previous post. An important not that I'd want to add to those results is that it seems that you're still losing a significant percentage of your samples when the server VI is on the windows side... do you see similar behavior with the plain simple TCP example (without modifications)? Also, by my calculations, the number of lost samples seems extremely high given the wait amount you've included in the code you attached; how long does either side take to error out (seconds/minutes)? Another good way to test whether communication is still ongoing after connection loss would be to write error messages and packet string length to a log file for each packet as it is sent; this should help determine when and where an error pops up.

[nanocyte]

---

@danniwithNI wrote:

Hi nanocyte,

I wouldn't expect the modifications you made to affect the TCP communication between the devices, but I'm still having trouble seeing the same magnitude of lost samples that you've logged in your previous post. An important not that I'd want to add to those results is that it seems that you're still losing a significant percentage of your samples when the server VI is on the windows side... do you see similar behavior with the plain simple TCP example (without modifications)?

---

I'm not clear on what experiment you want me to run here. You want me to take the shipping example, modify it to count packets and run the server on the RIO?

---

@danniwithNI wrote:

Also, by my calculations, the number of lost samples seems extremely high given the wait amount you've included in the code you attached; how long does either side take to error out (seconds/minutes)?

Using the VIs from the zip files I attached back at forum post 8 which is fairly close to the original, it takes ~10 minutes to send the >2000 messages before the server sees a write error.

---

@danniwithNI wrote:

Another good way to test whether communication is still ongoing after connection loss would be to write error messages and packet string length to a log file for each packet as it is sent; this should help determine when and where an error pops up.

---

I ran the log it looks like this:

itteration, first "bytes written", second "bytes written", first write error, second write error

0,4,40,0,0

1,4,40,0,0

...

2488,4,40,0,0

2489,4,16,0,56

Keep in mind that I pull the plug soon after connecting. The client running on windows received 32 messages.

How much loss are you seeing?

[danniwithNI]

Hi nanocyte,

Without any further modifications past what I mentioned in my earlier post (removing the error filter in favor of an error indicator), it only took .04 seconds for my TCP example to error out with error 56 (with the server on a RIO) after I disconnected it. Similarly, it took .2 seconds for the example to error out with a "waiting for target to connect" message then error 66 with the server on Windows. Because of this large discrepancy from your results, I'm curious as to how long (time-wise) your Simple TCP example takes to error out if unmodified.

[nanocyte]

When you say "disconnect it" you mean physically unplugging the cable right? I'm not clear on how you can measure the time between the code throwing an error and a physical action with sub second precision.

Making my code as close to the original as possible while maintaining the logging code, my server disconnects in ~50 seconds. It sent 335 messages (each having no error and 400 "bytes written") where the client only received 63 messages.

If I try and run the original server code on windows with RT as the client, the client code disconnects with error 56 without me even pulling the cable. That was one of the original motivations for modifying the code.

Any chance you could try the code I posted so we can see what sort of loss you are seeing?

[Davidvilla87]

Hello nanocyte,

I am seeing that this is taking some time, there has been a lot of interaction with Danni. What I recommend in this case is to create a service request with us, so we can give you a closer customer support experience. Have you had some improvements by now? Or are you on the same status as the beggining?

[danniwithNI]

Hi nanocyte,

To answer your questions, by "disconnect" I mean that I physically disconnected the RIO from my network and used the windows clock as my time reference to get an approximate gauge of time passage between the disconnect and the VI responding with an error. I did actually test the code that you posted, and after a disconnect I saw very similar timing results to the ones I saw with the basic example code. With RT as the server, I after about 8 seconds I got a message asking to disconnect from an unresponsive target, upon which I saw 0 sent messages on the server and 31 received on the client.

I was able to successfully use the original example code with RT as both server and client, so if you're having trouble with that code it may be that the IP addresses or serial ports aren't configured correctly (the most common reason why error 56 would automatically pop up), or some other factor coming from your network connection.

As David mentioned in his last post, Moving forward I'd recommend that you create a service request with NI support, since we've been working one-on-one on this forum post for a while and the forums aren't always the most efficient place for one-on-one troubleshooting.