* * *

Author Topic: Simple way how to communicate with service written in FPC  (Read 669 times)


  • Newbie
  • Posts: 1
Simple way how to communicate with service written in FPC
« on: February 20, 2016, 05:07:45 pm »
I am looking into possibility of porting one of our projects from Delphi/Windows to FPC(Lazarus)/Linux. Now it is a server application running as standard Windows GUI program. It accepts connections from clients and provides means of communication between them. It has one simple form with list of currently connected clients and one button to disconnect a client.

While porting it to linux I would like to change it to simple service without any GUI that would be controlled by system init daemon. I find this more systematic and I could get rid of all LCL/VCL, Xwindow/Desktop Evironment, etc... One of the desired platform would be Raspberry Pi 2 so every unnecessary running program may consume valuable resources. However I would like to keep the possibility to do simple communication with the running service. I do not mean logging, logging is already implemented on Windows and works fine, I need a "little interactive" method.

The basic point is that this should not make the service more complicated and should not impact the stability of the service. I would also like to avoid using more threads or child processes if possible. I do not mind creating separate application (maybe even with GUI) to communicate with the user but the part in the service should be kept as simple as possible.

So far I've come up with these options:

  • Use Lazarus instead of plain FPC, add form and basically keep the behavior same as on Windows. This would be the least complicated way but I already mentioned reasons why I would like to avoid it. But it is also the "safest" option in means of introducing new problems to the code
  • Catch signals to dump actual state to the log. There is a limited number of signals so the communication would be less interactive. But the required code would be rather short and simple (the service is already catching signals to be able to stop properly and is already logging)
  • Periodically read/write files in some state directory (probably on tmpfs) to mimick /sys. This seems like a simple way but I somehow feel like doing something periodically is not the right way :-) Maybe if it would be combined with the signals (as mentioned in previous option) so the service would catch the signal, read commands from one file and dumped the response to other file... Benefit would be that I could use standard linux tools to communicate with the service
  • Implement unix socket/TCPIP protocol to connect to the running daemon to control it. This seems like a "proper" solution but I think its rather complicated with many possible problems. Actually big part of the service is handling connections from all the clients in a way that they do not block themselves and that they do not conflict in any way and most production problems with the service has been caused by some problems with networking...

What way would you recommend?



Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus