0

The problem is over-complicated. A much straightforward solution is to redesign as Uwe and David suggested:

(1) Worker app. (2) Long-running TcpServer, that awaits clients and calls workers (3) Clients.

========================

I would like to build a SampleApp that functions as:

  • When started, it checks if there is already SampleApp running;
  • If not, it starts a TcpServer, a TcpClient, passes certain command from its TcpClient to its TcpServer, does the work, closes the TcpServer, and quits;
  • If yes, it starts a TcpClient, passes the command to the other's TcpServer and quits. (The other's TcpServer will do the work.)
  • There may be multiple SampleApp started when the first one is still running.

I have no idea about how to solve this problem practically, for example :

  1. Which architecture to start with ? ( The reputed OmniThreadLibrary seems to deal with thread-based concurrency instead of OS-process-based concurrency. )
  2. There is no SampleApp running. Two SampleApp are started (almost) simultaneously. How to guarantee only one TcpServer is started? (There is no "global list" to register the incoming "players".)
  3. There is one SampleApp running. How to handle if a 2nd detects the 1st's mutex and thus decides to be a TcpClient, but the 1st stops its TcpServer and quits?

Any insights are appreciated!

SOUser
  • 3,802
  • 5
  • 33
  • 63
  • possible duplicate of [How to I ensure only a single instance of my application runs using Delphi XE?](http://stackoverflow.com/questions/5390412/how-to-i-ensure-only-a-single-instance-of-my-application-runs-using-delphi-xe) or http://stackoverflow.com/questions/459554/how-can-i-tell-if-another-instance-of-my-program-is-already-running etc. OTL is not the answer here. – David Heffernan Aug 28 '13 at 15:20
  • That thread seems to give no solution to my problem. For example, how to deal if the 2nd detects the 1st's mutex and thus decides to be a TcpClient, but the 1st stops its TcpServer and quits? – SOUser Aug 28 '13 at 15:23
  • I don't see that scenario in your question. – David Heffernan Aug 28 '13 at 15:28
  • You will **always** have a little overhead time in startup/shutdown, so the possibility of one not seeing the other can never be prevented, only minimized. – Jan Doggen Aug 28 '13 at 15:30
  • @DavidHeffernan Sorry I did not explicitly mention the scenario. I listed two example problems, and thought `process-based concurrency` could mean more. I would think strictly speaking, singleton/mutex is not concurrency anyway. – SOUser Aug 28 '13 at 15:42
  • @JanDoggen Never? I thought there must be some way. (For example, in text books, concurrency is crucial for banks. There should be no leaks at all?) – SOUser Aug 28 '13 at 15:44
  • Singleton/mutex is synchronization. Which appears to be a large part of what you want to do. If you synchronize then your not explicitly mentioned scenario cannot arise. – David Heffernan Aug 28 '13 at 15:48
  • 1
    Why not start the tcpserver as a service when Windows starts and let it run forever? – Uwe Raabe Aug 28 '13 at 15:48
  • @DavidHeffernan Great! Could you help to comment how to synchronize between OS-processes? (For example, to synchronize within thread, one has critical section.) – SOUser Aug 28 '13 at 15:50
  • Use a mutex or a semaphore for between process synchronisation. And as Uwe says, be prepared to consider different overall designs. – David Heffernan Aug 28 '13 at 15:53
  • @UweRaabe I hesitate because the quality of this `SampleApp` is only amature grade. I mean, multiple `SampleApp` will be run automatically. I don't know what to do with the in-coming clients do if the TcpServer is started as service, raises one exception and halts? If the TcpServer is started at the same time as `SampleApp`, error cases will not hurt so much. – SOUser Aug 28 '13 at 15:54
  • @DavidHeffernan Great! I will try to learn how to use mutex or semaphore for inter-process synchronization. – SOUser Aug 28 '13 at 16:00
  • @DavidHeffernan "Singleton/mutex is synchronization. Which appears to be a large part of what you want to do. If you synchronize then your not explicitly mentioned scenario cannot arise." Could you please be more specific? Sorry but I still don't know how to handle the "lap" between "checking mutex" and "server quits/client tries to connect", after checking various wiki definition links. – SOUser Aug 28 '13 at 16:19
  • I don't understand your problem well enough to be more specific. – David Heffernan Aug 28 '13 at 16:23

1 Answers1

0

If you want to use this primarily to communicate between processes on a single computer (in a single user session), you should like at ActiveX Automation Objects. Creating a COM object that uses a LocalServer will do the starting and stopping of the 'server' process for you.

See more here: http://docwiki.embarcadero.com/RADStudio/XE4/en/Creating_an_Active_Server_Object

In case you insist on using TTcpServer, when two processes start (almost) simultaneously, still only one is allowed to bind to a certain TCP port, and the other will get an exception when calling Listen on the TTcpServer.

Stijn Sanders
  • 35,982
  • 11
  • 45
  • 67