I'm writing a C++ background/server application for Linux/Windows. Is there a standard control/profiling/reporting service I should use to expose my application's current status in a standardized way?
If not, what's a good pattern (or library) to use for exposing this kind of data and control?
Specifically, I want to expose the following data:
Relative "usage" of "components" (where usage/components is user-defined)
Any errors/faults
Memory, CPU, other misc process data
Method/class execution profile
Average time spent in method/class
Total calls
I want to expose the following control mechanisms
Start, stop, restart, reload X... (commandesque control)
Parameter tuning
Many Linux systems now have dbus for this sort of stuff. Daemons run and provide information and a control interface on the system bus. Desktop applications communicate with one another via the session bus.
For instance, the bluez bluetoothd daemon uses dbus to provide information about bluetooth devices and services, and a control interface to control those devices.
NetworkManager also uses dbus for status and control purposes.
However, starting and stopping are functions that are usually outside the actual application itself. Perhaps the correct architecture would be for some service supervision framework (upstart, runit...) to provide a dbus interface to control services. That said, dbus itself can be used to start services on demand, but it really is not meant for service supervision. See this for more.
Edit: I've just been reading about upstart some more, and it does have a dbus interface for job control. It is subject to change however.
Related
We have 2 systems between which we want messages to be exchanged. I am currently designing the application and have been given 2 choices.
System 1 to push messages to an intermediate location (FTP or SQS) and system 2 (running BizTalk) reading the messages from that location and processing it.
Exposing Schema/Orchestration as a web service in system 2 which would be consumed by system 1.
Any suggestions which method would be better in terms of error handling and scalability.
If you can, always go for an asynchronous approach, through a queuing system. This way, your application can be running independent of your back end. And then I would advise for Service Bus for Windows Server (heavier installation), Windows Azure Service Bus (as a service, in the cloud, internet connection needed) or with MSMQ (store and forward included!). These provide transactional behavior and can be considered as very reliable. Other lightweight options are indeed through file exchange or FTP.
Web service or REST connectivity is also very easy to set up, but then you have synchronous behavior, which has its benefits:
you can get a 'real-time' ack back when your message is delivered by BizTalk
it's easy to set up and to monitor
So, as mostly, the answer is 'it depends'.
There's only a 'best way' for you particular app and there are a number of conditions to consider.
The easiest way is a shared location on the File System (OS File System vs FTP doesn't matter so much), especially if order is not important.
If order has to be maintained to there's a guaranteed delivery requirement, then a Message Queue is a good choice, MSMQ/WMQ.
Of course, HTTP/SOAP is always an option.
Realistically, any of these methods will get the message there so you have to consider the benefits of each protocol.
I am working on app (c++) that consist from two parts.
Control Panel working under restricted user account (with UAC enabled)
Windows Service, performing some useful tasks
I need to collect user preferences in control panel and send them to service.
What is the best method for sending/receiving data from control panel to service?
The sockets and named pipes are good, but they may cause windows firewall to show security warnings.
Shared memory also is good, but it requires a lot of synchronization between sending and receiving threads.
Is there any other method that I can use?
Thanks,
Khachatur
Shared memory requires three extra mutex objects on each side. Not so much. If you don't want to write anything, our MsgConnect (open-source) implements MMF transport and has a sample of communicating between the service and the UI application.
Right now I have:
a multithreaded windows service written in C++ which use common static libraries as well as dynamic DLLs;
each thread performs different tasks and produces different errors (DB errors, function invocation errors, etc.). Each thread further will act as a logger client (and will send all messages to a logger server);
a separate thread which has no body yet, but which will act as a logger server for handling all log messages from the logger clients.
I need a good advise of how I should implement following idea into a working solution. The idea is to add a server-client logging architecture to my multithreaded server with following requirements (though some parts I need to implement by myself, please consider just the basic idea of logger client and logger server):
there should be a lot of log clients (as I already mentioned, the log client is just an existed working thread), each should register an entity with a unique name or/and ID and following behavior:
if the logger server is up and is working now, this log client starts to send log messages,
otherwise (the logger server is down), the log client endlessly tries to register itself with the log server using a small timeout.
there should be a logger server, with following behavior:
log server registers all log clients with their unique name or/an ID and endlessly checks if there appears a new log client to be registered
log server handles all messages from different log clients and writes to DB, file, etc.
there should be an opportunity to establish connection to the log server from an external application (for example, MySuperThreadViewerProgram to monitor all thread activity/errors/etc). At the connection, the log server should consider an external application as a one more log client. It's the most important requirement.
Summing up, there are three architecture parts to be implemented:
Server-client logger architecture;
Message queue facility between log clients and log server. And log server periodically checks if there any available log clients to be registered;
Inter-process communication between log server and external application, where the latter acts as a new log client.
Please, note, I consider a logger server as a kind of log message router.
So, the main question is:
Is there any solution (software framework) which has all described above features (which is much preferably) or I should use different libraries for different parts?
If the answer is: "there is no such solution", can you review the choice I made:
For #1: using Pantheios logger framework;
For #2: using any kind of register-subscribe library with server-client architecture and message-queue support (update: ipc library) ;
For #3: using Boost.Interprocess - using SharedMemory.
UPDATE:
The good example of #2 is this ipc library. And may be I was a bit incorrect describing logger client - logger server relations, but what I really mean is similar to approach, fully described and implemented in ipc library: when one entity (thread) subscribes to another to receive its messages (or "publish-subscribe" model).
And I want to use a kind of this technique to implement my logging architecture. But in what way?
UPDATE2:
OS is Windows. Yeah, I know, under Linux there is a bunch of useful tools and frameworks (D-Bus, Syslog). May be some of you could provide a helpful link to cross-platform library, which can be useful? Maybe there is a logger framework over D-Bus under Windows?
Any comments are highly appreciated.
Thanks a lot!
ØMQ (ZeroMQ) might be a viable alternative to the ipc library you mentioned, as it has a lot of features along the lines of your requirements.
It fully supports the PUB/SUB model, allows you to work between threads, bteween processes and even between machines. It is a client-server architecture, a message queue and works as IPC, too.
Of course, you need a specific way of coding and decoding messages, the protocol buffers are indeed a great idea.
As far as I know the logging backend pantheios uses (i.e. the log sink: DB, file or whatever) is specified at link-time. The severity of logs going to the backend can be specified at launch-time and with some simple tweaks also during runtime.
If I got you right, then you have one process (let's forget about the external application just for a minute) with multiple worker threads running. Some of these threads should log to a common backend (e.g. DB) and some to another. Because pantheios cannot do this out-of-the-box you'll need to write a custom backend that can route the logs to the correct backend.
If memory consumption is not an issue and you don't need the fastest logging performance, then you might want to look into log4cxx, because it is highly configurable and could possibly spare you from implementing a client-server-architecture with all the synchronization-problems it brings about.
About the external application: If you can guarantee, that it's only one external client, then you could use a pipe mechanism to communicate with the service. The service process would then have a separate thread, which corresponds to your server thread, that opens a named pipe and can also be specified as a log sink so your worker threads can log to it as well as to other log sinks (DB, file etc.).
There are some syslog servers for win as well. Winsyslog for example is coming from the producers of the famous rsyslog. Once you have syslogd running on win, there are plenty of OS independent syslog clients, such as SysLog4j if you're using Java, or the Syslog handler for the std. python logging.
i am writing an program in c++ and i need an web interface to control the program and which will be efficient and best programming language ...
Your application will just have to listen to messages from the network that your web application would send to it.
Any web application (whatever the language) implementation could use sockets so don't worry about the details, just make sure your application manage messages that you made a protocol for.
Now, if you want to keep it all C++, you could use CPPCMS for your web application.
If it were Windows, I could advice you to register some COM component for your program. At least from ASP.NET it is easily accessible.
You could try some in-memory exchange techniques like reading/writing over a localhost socket connection. It however requires you to design some exchange protocol first.
Or data exchange via a database. You program writes/reads data from the database, the web front-end reads/writes data to the database.
You could use a framework like Thrift to communicate between a PHP/Python/Ruby/whatever webapp and a C++ daemon, or you could even go the extra mile (probably harder than just using something like Thrift) and write language bindings for the scripting language of your choice.
Either of the two options gives you the ability to write web-facing code in a language more suitable for the task while keeping the "heavy lifting" in C++.
Did you take a look at Wt? It's a widget-centric C++ framework for web applications, has a solid MVC system, an ORM, ...
The Win32 API method.
MSDN - Getting Started with Winsock:
http://msdn.microsoft.com/en-us/library/ms738545%28v=VS.85%29.aspx
(Since you didn't specify an OS, we're assuming Windows)
This is not as simple as it seems!
There is a mis-match between your C++ program (which presumibly is long running otherwise why would it need controlling) and a typical web program which starts up when it receives the http request and dies once the reply is sent.
You could possibly use one of the Java based web servers where it is possible to have a long running task.
Alternatively you could use a database or other storage as the communication medium:-
You program periodically writes it current status to a well know table, when a user invokes the control application it reads the current status and gives an appropriate set of options to the user which can then be stored in the DB, and actioned by your program the next time it polls for a request.
This works better if you have a queuing mechanism avaiable, as it can then be event driven rather than polled.
Go PHP :) Look at this Program execution Functions
What would be the simplest way for an application I'm writing to block all Internet access on a Windows machine?
More details:
Windows: XP or higher
Application: A basic Win32 app written in C/C++.
Blocking: It needs to be able to block and unblock at will, ideally in a way that the user can't easily reverse. (By, say, right clicking on a network connection icon in the system tray.) Also, ideally, I'd like the method it uses to allow access to be restored should the user restart Windows or reset the machine, though I'd also be willing to have the app auto launch with Windows and unblock access upon startup if the machine was reset while in a blocked state.
Internet access: Primarily, I'd like to block conventional browsers from hitting conventional http/https sites. Secondarily, it would be nice to block IM clients and client-side social networking apps. It would also be nice, but not required, to still allow local networking for file sharing, etc. (Note that only the first requirement is absolute.)
Final notes: This is not meant to be a security utility, nor will its relationship to the user be adversarial (as, for example, with a parental control utility) so it's not important for it to use a scheme that can't be worked around by a determined user. (Consider that I intend for a reboot or reset to clear the blocking. This means that any workaround a user might discover that would take more effort than this is okay.)
Thanks!
p.s. I suspect that the Windows Firewall API won't work for me because this needs to work for users that haven't enabled the firewall or don't have admin privileges, but I'll be thrilled if I'm corrected on this.
It sounds like you're intending to run applications that you don't want to access the internet. Perhaps you could run them inside a virtual machine such as VirtualBox with networking disabled.
You could do it with a Winsock SPI. The Windows SDK has a sample (under Samples\netds\winsock\lsp) which implements what is called a layered service provider which allows you to hook all the user mode functions provided by Winsock and reject/modify the calls to block network access or redirect traffic to different locations. All installed winsock applications will be affected, so in your code you could have policys for what applications can go out and the like and disabled/enable on the fly. Now a determined person could find ways around this but it would be a pain.
That said this isn't trivial to do but the sample should get you most of the way there.
You cannot effectively or practically write your tool with only a user mode application.
What you need to write is a network I/O stack filter driver. This done by writing a Windows Driver. This is different from a Windows Win32 application. Drivers run in kernel mode and applications run in user mode.
On Windows Vista and later, the kernel mode Network Programming Interface (NPI) is designed for this. This is the same API that Windows Firewalls use. These are sometimes called the Winsock kernel (WSK) APIs.
In effect, you are writing a network firewall (more or less)
here are some links
Introduction to Winsock Kernel (WSK)
Windows Core Networking Blog
The Network Programming Interface Docs on MSDN
Note, your will likely need at least two components
Your driver
A Graphical application that a person can use to control your tool
If you want to do any monitoring, you will likely need a user mode service that collects data from your driver. This works better than trying to do this in the driver. In general, you should do the minimal amount of work in the driver.
A few notes:
You need to be very conscious of security when writing this kind of software. This is very much non trivial. Software that is network facing has the highest security requirements.
Be cognizant of performance.
Your driver and/or service must be aware of the context of a calling application. This is also a security boundary. For example, an application not running as administrator should not be able to control your driver.
take a look at firewall sourcecodes