1

I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.

The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).

Which is one more reliable or a "best practice":

  • Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
  • use WCF to somehow access admin/maintenance methods inside the assembly?

Thanks in advance for the nearly always useful feedback.

EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.

EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!

kmarks2
  • 4,755
  • 10
  • 48
  • 77
  • 1
    Can you use [custom service commands](http://stackoverflow.com/questions/3695245/how-to-send-a-custom-command-to-a-net-windows-service-from-net-code)? Might not be enough if you need to send a lot of parameters with your commands, and/or have the service return data. – Blorgbeard Feb 03 '12 at 20:57
  • 1
    @Blorgbeard This is a good starting place. As for now I do need to get return values (like lists of connected clients, cache size/count details, etc. Is that possible with your the technique you link to? Thanks again. – kmarks2 Feb 03 '12 at 21:00
  • With WCF the transport can be configured to run over a number of options including TCP and HTTP. Since it's running local, you can also use Named Pipes which is probably easiest and likely faster than developing custom TCP socket protocol. – kenny Feb 03 '12 at 21:01

2 Answers2

2

I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).

This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.

Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service

ken2k
  • 48,145
  • 10
  • 116
  • 176
  • 1
    Thanks. I'm looking into this if for no other reason that I probably eventually need to know WCF. – kmarks2 Feb 03 '12 at 21:18
0

You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.

You can have then a restful interface on top of it. WCF always seemed too heavy to my liking

mfeingold
  • 7,094
  • 4
  • 37
  • 43
  • Thanks for the feedback. Is there anything else besides WPF? The server is already written and done. I'm just trying to have a userland application send commands to the service and get info in return. – kmarks2 Feb 03 '12 at 21:24