Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Service with seperate GUI app
- Thread starter lloydie2
- Start date
buho
Programmer
- Jan 31, 2004
- 511
1) You can make an "interactive service", which can interact with the desktop, so you can use most of the normal interface techniques (windows messages and so on).
On the other side, interactive services can posse some security problems and, very important, making VCL objects(particulary forms) work in services is a royal pain.
If you have little experience in services, better stay out.
2) You can make a normal service and interface it with a normal application in some ways:
2.1) Using pipes. The Windows preferred method. I don't like pipes too much, I think the model id missguided.
2.2) Using virtual files. A quick (and may be dirty) method if you have not much different info to transmit (say you are only transmitting "x of total" info like in a process meter).
2.3) Using sockets. Kinda inefficient resource wise but my preferred method when I have complex protocols to comunicate.
2.4) Other crazy methods like registry keys. Not recomended in general (can be of use in very specific cases).
Feel free to ask about any concrete doubt you can have. Regrettabily, the issue is so broad to give you an overview.
Tell me some more about what the service make and what things are you interfacing and I'll give you some more precise opinions.
buho (A).
On the other side, interactive services can posse some security problems and, very important, making VCL objects(particulary forms) work in services is a royal pain.
If you have little experience in services, better stay out.
2) You can make a normal service and interface it with a normal application in some ways:
2.1) Using pipes. The Windows preferred method. I don't like pipes too much, I think the model id missguided.
2.2) Using virtual files. A quick (and may be dirty) method if you have not much different info to transmit (say you are only transmitting "x of total" info like in a process meter).
2.3) Using sockets. Kinda inefficient resource wise but my preferred method when I have complex protocols to comunicate.
2.4) Other crazy methods like registry keys. Not recomended in general (can be of use in very specific cases).
Feel free to ask about any concrete doubt you can have. Regrettabily, the issue is so broad to give you an overview.
Tell me some more about what the service make and what things are you interfacing and I'll give you some more precise opinions.
buho (A).
I've written quite a few of these sorts of applications, and I've only ever used sockets (using Indy TidTCPServer and TidTCPClient). I've found them to work quite well.
buho is correct when suggesting security is poor with this setup and I agree to an extent. It depends on how secure you need it to be. When writing the protocol, I usually use something like this:
1. GUI (client) connects to Service (server)
2. GUI sends ID string plus version number
3. Service checks ID string and version number to ensure it knows how to communicate with this particular client, sends 'OK' to client.
4. Communication proceeds.
You could make this more secure by writing a simple challenge/response algorithm so that someone with a sniffer would be unable to break in without knowing your algorithm. Then the availablity of the source code for both programs becomes the weak point.
The major benefit with the socket approach is that it will work well across subnets, across the internet, VPNs etc.
buho is correct when suggesting security is poor with this setup and I agree to an extent. It depends on how secure you need it to be. When writing the protocol, I usually use something like this:
1. GUI (client) connects to Service (server)
2. GUI sends ID string plus version number
3. Service checks ID string and version number to ensure it knows how to communicate with this particular client, sends 'OK' to client.
4. Communication proceeds.
You could make this more secure by writing a simple challenge/response algorithm so that someone with a sniffer would be unable to break in without knowing your algorithm. Then the availablity of the source code for both programs becomes the weak point.
The major benefit with the socket approach is that it will work well across subnets, across the internet, VPNs etc.
- Thread starter
- #4
- Status
Similar threads
- Locked
- News