executables

[Mark_Yedinak]

---

@Paul_R. wrote:

I failed to mention that I am using TCP/IP protocol to communicate between a client and a server.  Could this also play a factor?  And if so, what are some of the issues that this may present?

Thanks,

Paul

---

Rather than dribble out tiny bits of information why don't you post teh code that you suspect is giving you the issue. Also, are you using names for your addresses or are you entering specific IP addresses? If you are using names you could be running into delays resulting from DNS lookups. Again though, without seeing the code all we can do is guess.

[Paul_R.]

The program, that is slower as an executable when run locally, is the server.  As for speed, it takes 2-3 seconds for the server to start executing the command from the client when both are non-executables.  It takes approximately 15 seconds when they are both executables.

[Paul_R.]

Attached are the vis that create the client-server connection.

[Mark_Yedinak]

Why do you include timeouts for your listener on the server? When you are waiting for a connection you should just wait the hole time. Depending on how you start your code up in the executable you could get into a situation where the server is not listening and miss the open connection from the client. The client will then wait for 10 seconds. Do you see where this is headed? On your server you should create the listener explicitly outside your loop. When you need to exit your code you can close the listener which will abort the Wait on Listener (this will replace your TCP Listen).

Also, are your messages guaranteed to be 512 bytes? If not you should either prepend the length of the message to your data and perform two reads. One to read the number of bytes to read and teh second to read the actual data. Alternatively you do have an End of TX character which you could use to determine when to stop reading data. This will not work though if your data is binary. Also, you will either need to read the data 1 byte at a time and check for the ETX or read larger buffers and search for the ETX> However if you do this you will need to buffer the data that was after the ETX.

I would also change your code and remove the global variables. You could easily be running into race consitions since you use them quite a bit. I hope you are not sharing the global variables between the server and the client. If you are that is a poor design since the will always need to be running in the same process.

[Paul_R.]

Mark,

Here is a dumb question.  How do you close the listener, if it does not have a timeout?  It seems that the program just waits indefinitely for a connection and it cannot be interrupted.

[Mark_Yedinak]

Use a second parllel loop that would monitor a stop button or some othe rmechanism to initiate a stop. The Create Listener would be outside both loops and the reference returned would be passed to both loops.

Here was an example server I posted a while back. Notice the Create Listener on the left outside of both loops. When the event structure detects the Stop button being depressed it exist the top loop. The Close Connection for the listener is on the right and because of data flow will run after the first loops terminates. That will result in an error for the Wait on Listener if it is waiting for a connection.

[Paul_R.]

What if the "Wait On Listener" never gets a connection?  The vi will just sit there waiting.

[Mark_Yedinak]

---

@Paul_R. wrote:

What if the "Wait On Listener" never gets a connection?  The vi will just sit there waiting.

---

If you close the listener reference the Wait On Listener will exit.