Like title,
Is it possible in some way to get processes that are hooked to your application?
Either directly, or via DLLs?
My application is written in C++ and it can obtain processes, windows, and DLLs just fine.
But I noticed that some "bots" can connect to it, without leaving an obvious DLL-trace which makes me forced to find other solutions on how to track bots.
You don't have to know anything about bots or so.. any answers to my primary question are very appreciated no matter your experience.
Thanks in advance!
How does ZeroC ICE compare to 0MQ? I know that 0MQ/Crossroads and DDS are very similar, but cant seem to figure out where ICE comes in.
I need to quickly implement a system that offloads real-time market-data from C++ to C#, as a first phase of my project. The next phase will be to implement an Event Based architecture with an underlying Pub/Sub design.
I am willing to use TCP.. but the the system is currently running on a single 24 core server.. so an IPC option would be nice. From what I understand ICE is only TCP, while DDS and 0mq have an IPC option.
Currently ,I am leaning towards using Protobuf with either ICE or Crossroads IO. Got turned off from the OpenSplice DDS website. Ive done lots research on the various options, was originally considering OpenMPI + boost:mpi, but there does not seem to be MPI for .NET.
My question is:
How does ICE compare to 0MQ? I cant wrap my head around this. Was unable to find anything online that compares the two.
thanks in advance.
........
More about my project:
Currently using CMAKE C++ on Windows, but the plan is to move to CentOS at some point. An additional desired feature is to store the tic data and all the messages in a "NoSql" database such as Hbase/Hadoop or HDF5. Do any of these middleware/messaging/pub-sub libraries have any database integration?
Some thoughts about ZeroC:
Very fast; Able to have multiple endpoints; Able to load balance on the endpoints; Able to reconnect to a different endpoint in case one of the node goes down. This is transparent to the end user; Has good tool chain (IceGrid, IceStorm, IceBox, etc); Distributed, high availability, multiple failover, etc
Apart from that, I have used it for hot swapping code modules (something similar to Erlang) by having the client create the proxy with multiple endpoints, and later on bring down each endpoint for a quick upgrade one by one. With the transparent retry to a different endpoint, I could have the system up and running the whole time i did an upgrade. Not sure if this is an advertised feature or an unadvertised side-effect :)
Overall, it is very easy to scale out your servers if need be using ZeroC Ice.
I know ZeroMQ provides a fantastic set of tools and messaging patterns and I would keep using it for my pet projects. However, The problem that i see is that it is very easy to go overboard and lose track of all your distributed components. This is a must have in a distributed environment. How will you know where your clients/server are when you need to upgrade? If one of components down the chain does not receive a message, how to identify where the issue is? the publisher? the client? or any one of the bridges (REP/REQ, XREP/XREQ, etc) in between?
Overall, ZeroC provides a much better toolset and ecosystem for enterprise solutions.
And it is open source :)
Jaybny,
ZMQ:
If you want real good performance and the only job for Phase 1 of your job is to move data from C++ to C#, then Zmq is the best option.
Having a pub/sub model for event driven architecture is also something that Zmq can help you with, with its in-built messaging pattern.
Zmq also supports your IPC requirements in this case. Eg: you can have one instance of your application that consumes 24 cores by multithreading and communicating via IPC.
ZeroC Ice:
Ice is a RPC framework very much like CORBA.
Eg.
Socket/ZMQ - You send message over the wire. Read it at the other end, parse the message, do some action, etc.
ZeroC Ice - Create a contract between client and server. Contract is nothing but a template of a class. Now the client calls a proxy method of that class, and the server implements/actions it and returns the value. Thus, int result = mathClass.Add(10,20) is what the client calls. The method, parameters, etc is marshalled and sent to the server, server implements the Add method, returns the result, and the client gets 30 as the result. Thus on the client side, the api is nothing but a proxy for a servant running on a remote host.
Conclusion:
ZeroC ICE has some nice enterprisy features which are really good. However, for your project requirements, ZMQ is the right tool.
Hope this helps.
For me.. the correct answer was Crossroads I/O . It does everything I need.. but still unable to pub/sub when using protobufs... im sure ZeroC ICE is great for distributed IPC, but 0MQ/Crossroads, gives you the added flexibility to use Inter-Thread-Communication.
Note: on windows, 0mq does not have IPC.
So, all in all, the crossroads fork of 0mq is the best. but you will have to roll your own windows/ipc (or use tcp::127..) , and publisher side topic filtering features for pub/sub.
nanomsg, from the guy who wrote crossroads and 0mq (i think).
http://nanomsg.org/
I'm currently working on transitioning a small console application to a TCP server / client application. The client will connect to the server via any Telnet client, and the server will replicate the standard console interface for each Telnet connection.
I started looking into doing this using the techniques I've learned from Beej's guide to network programming -- accepting the connection and then using fork() to separate it into its own process.
However, I would prefer to maintain my use of streaming IO (the original console application uses cin / cout, using similar functions for the networking logic would make the conversion process much simpler).
I've discovered the TCPStream class, hiding within sockets.h (http://www.gnutelephony.org/doxy/bayonne2/a00215.html)
It appears this class will allow me to use the server with streaming IO. However, I can't find a single example of using this class, nor can I find an explanation as to how to use fork() with it.
Any ideas? Thanks in advance for any help.
I think you are confusing the trees for the forest. One socket class is such a small part of what you need to do overall that it is not worth focusing on that.
If your objective is just to get your project working then just use an existing framework rather than trying to pull individual classes out of a large project. POCO has a TCPServer class that will do 90% of the work for you. QT, ACE and others have similar classes. There is not a huge amount of documentation on POCO but they do cover TCPServer pretty well and you can learn a lot from reading the source code if that is really where your interest lies.
i would like to develop a c++ application that would list all url accessed with its response time within the pc. this probably would be transparent to the user, so it would be a dll.
can anyone gve me some sample codes or tutorials on th said matter.
or any tips and suggestion?!..
thanks alot:))
You should take a look at the fiddler plug-ins. This is not a trivial exercise. You need to do dependency injection to capture the wininet calls. Even so not all apps use the high level windows api to initiate connections. Applications that make TCP connections might last for a long time since not all TCP calls are simple web requests.
As Byron has said, this is a non-trivial exercise. You could do it using libpcap http://sourceforge.net/projects/libpcap/ having installed http://www.winpcap.org/ on Windows. Tutorials for using libpcap are around and you'd need to learn to filter out everything but http/https traffic, although once you've got to that stage it shouldn't be too hard. Try http://yuba.stanford.edu/~casado/pcap/section1.html for starters or http://systhread.net/texts/200805lpcap1.php. Both tutorials look reasonable.
I also feel I should point out that "transparent to the user" and "dll" are not equivalent ideas. A DLL is a set of library functions separate from an application that can be used by many applications - see http://en.wikipedia.org/wiki/Dynamic-link_library. A "standard" executable file (i.e. file ending in .exe) can still be transparent to the user if run, for example, as a Windows Service, which might be more what you are looking for.
I wrote a device controller (rs232) and it is being used successfully, however users want to view data and control the device (or perhaps communicate through my program) from Excel. I dismissed DDE as an option and found that RTD (IRtdServer) is probably a good start (though no way to send data back to the "server" from the real time data client).
I found these resources for the RTD part:
http://support.microsoft.com/?id=327215
and
http://support.microsoft.com/?id=327215
This is a multi-threaded app and I had already added the ability to have multiple listeners on the com port so that I could update multiple clients. I will add the COM interface to the EXE.
But what I need after that is some way of controlling my app/proxying commands to the device through my app from Excel.
What would be the best way to do that?
Perhaps another COM interface and calling it from VBA or something? I am not familiar with using scripting from Excel, so perhaps someone can provice sample code or links that show both the code for a COM object and the accompanying VB(A?) code?
Keep in mind that this is an unmanaged C++ application and it cannot be converted to managed or C# right now. Alternatives using C# are welcome as well, but that is a long-term rewrite.
Thanks
EDIT
I have an alternative to adding COM support into the existing EXE. I think it is more flexible to add a two-way communications (cross platform - maybe boost or corba or just straight IP based with my own message protocol)
A COM server (or two) can wrap that communications channel - whatever it is. This doesn;t really affect my question at all - I still would like to know the options for controlling an external EXE from Excel.
EDIT
Not having to roll out .NET to customers is also an big plus. many of these devices are on PCs that are pretty old and have perhaps NT or XP on them and I don't relish increasing my setup/install package from 700KB to the ridiculous .NET install size...
Option #1:
Create a small COM server - make sure its interfaces are suitable for scripting with the built Visual Basic engine in Excel. (e.g. use simple types and BSTRS).
Write Excel VB Macros to (1) add your own tool bar to excel and (2) call your COM server.
You can also add buttons and other UI elements to sheets and hook them them up to VB macros.
Option #2:
I realize that you do not want to use C# - but automating office, and talking to COM objects is really, really easy in C# with Visual Studio Tools for Office (VSTO). You shoul really look into this option - If done correctly, it shouldn't mean re-writing any of your existing code. Just use C# and VSTO as a bridge between Excel and your RTD server. As with VB, its straight froward to connect UI elements in Excel to C# and then to your RTD server.
Calling a COM object from VBA is straightforward. This SO Question and my answer give an example of how to create a COM object. Calling exposed methods is as you would expect:
object.ExposedMethod(optional params...);