Inter-Process object parsing RRS feed

  • Question

  • I have a series of products which run on different machines and I've used the same network architecture for two years now. I'd like to put more focus on implementing process analysis and being able to automatically restart products locally when process errors occur and also manually control startup and shutdown of processes remotely. I can do this much already so far. What I'd really like to do is also locally centralise network and SQL resources in the same application which starts and stops processes. This means I can develop the other applications without the need of referencing a shared library and to also greatly reduce downtime.

    The only non inter-process approach I know I can do is creating all the apps as libraries that implement a common interface. This would still achieve the desired resource centric approach I would like. However, the dynamic assembly still executes in the same process.

    The inter-process approach I would like to design starts the process, parses a class which encapsulates a TCP socket class or an SQL connection class on a per process basis. The sockets themselves are managed by the application which connects to remote machines and SQL servers. The 'child' process(es) would expect to be parsed these managed sockets, encapsulated in some form, for use immediately.

    Are any of these concepts far fetched? If not, do I have a solution which can be designed without the use of an unmanaged codebase?

    On a side note, I've recently been reading the MSDN Powershell documentation after I saw its use in the SQL Server 2008 installation. Can .Net applications make use of powershell to parse/pipe objects to other applications or does the native .Net runtime not support object oriented shell interfaces?
    Wednesday, April 29, 2009 2:56 AM

All replies

  • Please define "errors occur". Process crash? Or not responsive for a certain time?
    What is your networking constraint? (i e what kind of networking technologies are allowed to connect to your management server)
    You may want to collect performance data from Windows's performance counter for analysis. In addition, you may want to change your process to applications that run in a managed host like IIS worker processes. There are a lot of tools written to manage IIS worker processes.

    MSMVP VC++
    Wednesday, April 29, 2009 5:36 PM
  • Network technologies vary from venue to venue. Some are optic fibre linkes. Some are 200m wired ethernet and others 300m wireless outdoor bridges. The networking code I developed is solid in terms of reliability and fast recovery. Errors occur in front-end-user code and interface issues.

    The server is not technically a server machine. All machines used are laptops which either run  Win XP Pro or Vista Home so everything is designed without the usage of advanced services. Some of my clients are on the other side of the country as well so getting them to install software and SQL server is already a hard task let alone configuring IIS. Performance data isn't paramount. I'm more interested in the simple functionality that the Process class provides. Either running or not responding is fine. More advanced error reporting would be unique to the front-end-user application functionality and I'm going to create that anyway.

    I classify the main hub of data processing as the server. Most of the hardware devices are connected to it. All plug-ins, authentication, team databases and match day configuration is done through this 'server' software. Client applications that connect to it are served streams of data collected by the hardware devices. All the client applications are different in design and use. For better reliability during the match and reduction of downtime due to errors anywhere in the software network, I'd like to remove all networking and SQL based code from the server software and client applications. It will be bundled into a new, independent, application that pretty much runs as a Windows Service.

    The front end user applications and the server application will then connect to the local service to obtain sockets and SQL functionality from the Windows Service. To be more explicit about this, the applications will be executed via the service so they can be monitored. The reason being that the service will have a list of expected front-end-user applications that should be running on match day. The service also handles authentication since I use my own security code for remote systems connecting to the server. I don't want to be constantly scanning for processes which have been executed outside of the service. The service needs to be able to automatically create and maintain sockets between machines independently of front-end-user applications. The front-end-user applications should ideally just be able to start up and recieve sockets from the service to begin running immediately. Can objects be parsed to processes if for example, all applications are created using Managed .Net framework or even applications implementing a common Interface similar to using DLLs as plug-ins via Ssytem.Reflection.
    Wednesday, April 29, 2009 6:16 PM
  • I thought you are managing mission critical server processes. 

    If you don't want to pull data from processes constantly, you need to post data from from processes to tell your management software their status (hey I am still alive and will probably be alive for the next 5 minutes or so/ I am done, I am gone). 

    On your client you can code your processes to call Windows service that try to kill and recreate processes when a process failed to report in a certain time. You can use many IPC  methods but I suggest .Net remoting since you will write managed code. You may want to stop the process when the performance monitor says the computer is busy (whoa, why so many processes comes and goes when I am playing computer games?).

    MSMVP VC++
    Wednesday, April 29, 2009 6:54 PM
  • Have you considered using WMI calls to monitor process health?  Open up WMI to a central management server and have it cycle through the boxes to monitor and if it sees a process missing, start it up. 
    Wednesday, April 29, 2009 7:37 PM
  • Ok, i'll clear something up. Process monitoring will always be local. Monitoring the health is easy by using Process.GetProcessByName() etc etc. Starting processes will always be done locally as well. The remote component of it, I will code myself. Easily done. Each computer runs the background process I'm currently working on. It's designed to run in server or client mode. Something very much like the behaviour of VNC. In server mode, the software broadcasts UDP packets to the target IP pool so other machines running the software in client mode know that a server exists and can connect to it. The clients then make automatic TCP socket connections and provide credentials etc.

    For machines running in client mode, you have an interface for executing other applications which depend on the network link the background process has with the server. This link is NOT just for health monitoring. It also streams statistics and data acquired from the hardware devices I designed which are connected to the machine running in server mode.

    Lets call the machine running the background process in server mode, A, a machine running in client mode B and a process executed by B, C. The idea is that A & B are always connected. If the process C fails, B remains connected to A via TCP.

    C is dependent on the TCP socket B has with A. When the process C starts, B is required to share its socket with C. The statistics and hardware data from A need to reach C via the process B.

    If C fails, B has been monitoring C and restarts the process C and again shares the socket B has to A with C.

    B manages the socket state with A. It never sends or recieves data except when the socket is first created, B sends A an authentication key. C does not manage the socket. The process C assumes the socket is healthy and immediately begins to use it.

    Finally, processes A, B and C are all coded by me using the .Net framework.

    Code wise, this my understanding with the Process class and how I think I would like to implement it. Not sure if it's possible:

    //Code in process B
    TcpClient serverSocket = new TcpClient("IPAdressOfMachineA",PORTNUM);

    Process processC = new Process();
    processC.StartInfo.Filename = "pathOfProcessC//processC.exe";

    //Insert some implementation here which encapsulates serverSocket and parses it to processC

    To be honest, some aspects of the concept tell me there is a way of doing it and some don't. For example, Control.DoDragDrop(). It works between application domains but requires serialisation. I'm not sure if you can serialise the TcpClient class and parse it to another process. On the other hand, i'm not comfortable with two application domains using a shared memory space in different processes. I have no experience with that under Windows using Managed code.

    If there is no feasible way to do what i describe, I might just create TCP sockets between processes B and C on a different port to the socket between process A and B and just passthrough data from A to B then B to C but I'd like to avoid implementing any TCP socket management code in process C.
    Wednesday, April 29, 2009 10:44 PM