TCP/IP CLIENT ALWAYS RUNNING, HOW?

[Danybond]

Hi, i would like to know, if its possible to make a tcp / ip comunication but the client always running, i have two programs, one called "master" and other called "track point", master is a client and track point is the server, but server is going to be in a PC which at the end of the day is going to be turned off but master is always working, i want that at the next day, when i turn on the PC that contains the server "track point" comunicates to the client.
server starts to send information and client start to reads information.

How can i do that?

Thanks in advance.

[Mancho00]

Well, the obvious thing to do is reverse the roles.  Make "master" the server and "track point" the client.  If that's not possible for whatever reason, you can have your client, if it loses connection to the server, periodically check for a new server connection.

[Danybond]

yes, in actual fact im working on it, but as i dont have much experience using labview and this is the first time using tcp/ip i cant get it, i thought in a boolean to use as trigger and use a case structure to reverse server in client and vice versa

[Mancho00]

---

@Danybond wrote:

... i thought in a boolean to use as trigger and use a case structure to reverse server in client and vice versa

---

I'm not sure I understand. For TCP/IP you wouldn't usually want a boolean to determine whether something is a client or server.  Roles shouldn't be dynamically changed like that.  A server's role is to wait for a client connection/request and perform some action accordingly.  A client makes a connection to a server and sends and/or receives data to/from that server.

[Danybond]

ok ok, i have understood, you have gave me more idea, thank you.

[rolfk]

In TCP speak the server is a listener who starts up a loop that waits on a socket for connection requests. The server/listener MUST have been started by someone in order to be ready for connection requests. TCP/IP has no method to turn around these roles. The server/listener must be up and running by the time a client tries to connect to it. So this means automatically that your master should be the listener. Anything else only complicates the issue a lot.