Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. NT Service networking

NT Service networking

Scheduled Pinned Locked Moved C / C++ / MFC
questiontutorialc++designsysadmin
4 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    Greven
    wrote on last edited by
    #1

    I'm beginning work on an NT service (only in the early design phase right now) that will need to respond to network requests. I've done work with networking before, but this will be my first service. What I'm finding already is that there doesn't seem to be an easy way to handle networking. At least not as intuitive as through CSocket with MFC. What type of system does everyone else use for a service? I know I can setup a thread that continually tries to receive, and that might work. I've also looked into using the MFC service classes out there (PJ Naughter's in particular) so that I can use CSocket again. Both seem to have there up's and down's. Is there an easy way that I'm not seeing? Also, as a second question. How do you control a service? I understand how to start, stop, and pause them. But how do I grab it and call a function? Or can I? Basically, if I write a control panel applet for example, how do I adjust the service in realtime? I could always write adjustments to the registry, but then I would also have to have a thread watching for changes and that doesn't seem very logical either. Again, is there an easy way that I'm just not seeing? "Go Confidently in the direction of your dreams. Live the life you've imagined." - Thoreau

    D 1 Reply Last reply
    0
    • G Greven

      I'm beginning work on an NT service (only in the early design phase right now) that will need to respond to network requests. I've done work with networking before, but this will be my first service. What I'm finding already is that there doesn't seem to be an easy way to handle networking. At least not as intuitive as through CSocket with MFC. What type of system does everyone else use for a service? I know I can setup a thread that continually tries to receive, and that might work. I've also looked into using the MFC service classes out there (PJ Naughter's in particular) so that I can use CSocket again. Both seem to have there up's and down's. Is there an easy way that I'm not seeing? Also, as a second question. How do you control a service? I understand how to start, stop, and pause them. But how do I grab it and call a function? Or can I? Basically, if I write a control panel applet for example, how do I adjust the service in realtime? I could always write adjustments to the registry, but then I would also have to have a thread watching for changes and that doesn't seem very logical either. Again, is there an easy way that I'm just not seeing? "Go Confidently in the direction of your dreams. Live the life you've imagined." - Thoreau

      D Offline
      D Offline
      Daniel Lohmann
      wrote on last edited by
      #2

      To write your very first service is always a bit of hard work. However, it is not that difficult as it looks like: 1) To really work with a service you need some kind of inter-process-communication (IPC). IPC is the way to communicate with your service. Sockets are one example for IPC, I usually prefer NamedPipes or RPC (because they integrate well into the NT security modell), but one may also use shared memory, sockets, NetBIOS and so on. 2) Even if possible I recommend not using MFC in a service. For things like CString or CArray it is you can use the ATL/WTL classes that provide a compatible interface. Or use STL. Especially CSocket is a no-no. It is integreated to much into "windowing applications". 3) To control a service a CPL or MMC snap-in is a really good solution. You can monitor the registry as you suggested, but you could also inform the service about changes via a Win32 event object, IPC or a user defined service control code. The last one is elegant because you don't need an own watcher thread. 4) Debugging a service is a bit hard, because it is not possible to run it directly under the debugger. However, you could connect your debugger later on to the service (via task manager). To debug service startup code a hardcoded breakpoint works best. // some code _asm int 3 // Program will break here // some more code If the code reaches the hardcoded breakpoint, the usual "unhandled exception" dialog box will appear and give you the chance to attach the debugger. Hope that helps for the moment :-) -- Daniel Lohmann http://www.losoft.de/

      G 1 Reply Last reply
      0
      • D Daniel Lohmann

        To write your very first service is always a bit of hard work. However, it is not that difficult as it looks like: 1) To really work with a service you need some kind of inter-process-communication (IPC). IPC is the way to communicate with your service. Sockets are one example for IPC, I usually prefer NamedPipes or RPC (because they integrate well into the NT security modell), but one may also use shared memory, sockets, NetBIOS and so on. 2) Even if possible I recommend not using MFC in a service. For things like CString or CArray it is you can use the ATL/WTL classes that provide a compatible interface. Or use STL. Especially CSocket is a no-no. It is integreated to much into "windowing applications". 3) To control a service a CPL or MMC snap-in is a really good solution. You can monitor the registry as you suggested, but you could also inform the service about changes via a Win32 event object, IPC or a user defined service control code. The last one is elegant because you don't need an own watcher thread. 4) Debugging a service is a bit hard, because it is not possible to run it directly under the debugger. However, you could connect your debugger later on to the service (via task manager). To debug service startup code a hardcoded breakpoint works best. // some code _asm int 3 // Program will break here // some more code If the code reaches the hardcoded breakpoint, the usual "unhandled exception" dialog box will appear and give you the chance to attach the debugger. Hope that helps for the moment :-) -- Daniel Lohmann http://www.losoft.de/

        G Offline
        G Offline
        Greven
        wrote on last edited by
        #3

        Daniel Lohmann wrote: or a user defined service control code. The last one is elegant because you don't need an own watcher thread. What exactly do you mean by this? What is a user defined service control code? Also, if I do use normal socket code, is it common to have a looping thread that just sits there waiting to receive something? Programming in binary is as easy as 01 10 11.

        D 1 Reply Last reply
        0
        • G Greven

          Daniel Lohmann wrote: or a user defined service control code. The last one is elegant because you don't need an own watcher thread. What exactly do you mean by this? What is a user defined service control code? Also, if I do use normal socket code, is it common to have a looping thread that just sits there waiting to receive something? Programming in binary is as easy as 01 10 11.

          D Offline
          D Offline
          Daniel Lohmann
          wrote on last edited by
          #4

          Greven wrote: What exactly do you mean by this? What is a user defined service control code? Using the ControlService() API you can send control codes to a services' handler function. Besides the predefined control codes (SERVICE_CONTROL_STOP, SERVICE_CONTROL_PAUSE, etc.) the range 128-255 is reserbed for user-defined control codes. Greven wrote: Also, if I do use normal socket code, is it common to have a looping thread that just sits there waiting to receive something? Yes, there must be some thead that waits for recieving something. However, you could use overlapped IO so the thread is not blocked and can do also something else. You could even use the services' main thread for that purpose (the thread that starts in your ServiceMain). -- Daniel Lohmann http://www.losoft.de

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups