next »

[KaptainKrayola]

I have an interesting idea and w/o going into too much detail about it basically what I'm looking to do is have a windows service that maintains a connection to a certain place and also listens for instructions.

My question is really what are my options for communicating with this service?  Can another process talk to it and issue commands by calling methods on the service?  Right now the only option on the table is having it listen on a port over HTTP which is something I'd really rather not do.

What i'd like to be able to do is have another program running (such as a windows based GUI) that can issue commands to the service

One person suggested using named pipes for interprocess communication.

thoughts?

[perkiset]

I have an interesting idea and w/o going into too much detail about it basically what I'm looking to do is have a windows service that maintains a connection to a certain place and also listens for instructions.

HAHAHAHAHAHAHAHAHAHAHA Love it! So benevolent. So benign.

My question is really what are my options for communicating with this service?  Can another process talk to it and issue commands by calling methods on the service?  Right now the only option on the table is having it listen on a port over HTTP which is something I'd really rather not do.

What i'd like to be able to do is have another program running (such as a windows based GUI) that can issue commands to the service

Just use TCP. A service is simply special executable code that runs under a different execution umbrella than the standalone stack. The best part about TCP is that intra-machine it's instant, just about like any other service (there are quicker methods, but I don't assume we need to haggle sub-ms differences) yet it is also completely addressable inter-machine as well.



Where ya goin' there, boyo? Sounds like a bit of the old ultra-violence.

[KaptainKrayola]

it's part of this big old SMS service gateway i'm building.  I can't say too much about it in public but basically I want to be able to tell this windows service what to do from another process running on the same machine.  So it wont matter whether it's another C# app or something that can instantiate .net DLLs (like coldfusion) issuing the commands they can each tell the windows service what to do.

if you have some other ideas contact me on IM or something and i can explain a little more than I can here.

[nop_90]

overview of IPC
http://msdn.microsoft.com/en-us/library/aa365574%28v=VS.85%29.aspx

Pipes are probably the best bet.
If you can run the server as a non-service while u are testing.

[perkiset]

if you have some other ideas contact me on IM or something and i can explain a little more than I can here.

Nope, nothing specific except that I disagree with Nop, I'd do it with TCP since it's so very well understood. It is a little bit of a hitch to assume that a machine has a TCP stack running, but I've not seen a stand alone non-networked machine for years, so I think it's a fair gamble. Especially if this service is connected to SMS, in which case it is definitely on the net.

[nop_90]

@perks
It all depends what the application is for.
If it is just for in house, or a server, TCP is way to go.
Actually you could find a small webserver, embed it into the application, then fuk the gui and  make a web gui, and use that to control the application.

If it is an actual application for users, they might get upset with extra socket being open, if u know what i mean
You could start out with TCP.
If you do ur code properly abstract the actual TCP socket as in wrap it so that the send and recv are in class for each connection.
Then if u decide to go the pipe route then you could pull that part out and use a pipe.
That is the method used by http://rpyc.wikidot.com/tutorial

Another question is, does it actually need to be a service ?
as u said services run under a different user space. so for debugging it is a nightmare.
so if possible develop as a regular app then convert to service latter.

 

[perkiset]

@Nop - I'm wondering if the average user would even know that another socket was open 

Agree totally with debugging from a normal GUI space. Actually if the app was written as a class that did the work and a simple main() that called it, then re-compiling it as a service would be trivial. (I believe it's just a link switch or project option in most Windows IDEs)

I think there's one benefit (really, just about one) to the service approach: installed as root and run automatically, it would not be seen in the startup folders nor appear in anything other than the task manager. It would not be easily stoppable for the uninitiated nor set to manual rather than automatic startup. That said, on the other hand if it pukes then the average user will have a hell of a time finding it and restarting. Sort of 6 of 1 I guess..

Like the notion as well of encapsulating the interprocess comms so that if you wound up hating TCP or pipes or semaphore files FFS  then you can change the method without changing anything else in the app.

[nop_90]

@perks
make kap a member of the moderator forum.
That way we do not have to discuss here

[perkiset]

Has been for a long time mate

[nop_90]

The compiler switch is for a "windows" program vs a "console" program.
There actually is not difference, except it sets a byte inside the PE header in the exe.
If it is set as a "console" app then when it starts up it automatically creates a "console".
But a windows program can create a console using API.

For any language u can get a Windows Service helper, all it does is abstract the Service Callbacks.
http://msdn.microsoft.com/en-us/library/ms683240%28v=VS.85%29.aspx

Just like any gui proggie has a MessageLoop, a service has a message loop.
The important messages are when the service is told to start and stop.

installed as root and run automatically, it would not be seen in the startup folders nor appear in anything other than the task manager. It would not be easily stoppable for the uninitiated nor set to manual rather than automatic startup. That said, on the other hand if it pukes then the average user will have a hell of a time finding it and restarting. Sort of 6 of 1 I guess..

exactly
But it runs in a seperate environment. I have to play around with them some more

Hardest part of shit like that is the documentation sucks or is sometimes wrong.