Interrupts and Handling

[Harland]

Hey guys,

I was wondering if anyone has had some experience with sending interrupts and handling them, with a slight twist though. I'd like to send an Interrupt from my C++ DLL to a C# Controller program. Does anyone know if it is at all possible to do such a thing?

I can't quite seem to wrap my head around how C#'s delegates or events could at all be implemented with C++ signal() method.

The reason I am interested in such a task is because I don't want my C# app to be constantly polling DLL for a response.

Anyways thanks if someone could provide me with some suggestions, I'm kind of out of research terms to type into Google .

[Sednogmah]

You are looking for an IPC solution. (Inter-process communication).

There are several kinds of IPC systems. Some only implement shared memory and process synchronization while others have Remote Procedure Calls and message passing, for example:
- XML-RPC and SOAP: XML based RPC systems. Both are unnecessarily complex for your use case and also pretty slow due to the XML overhead.
- D-Bus: efficient IPC with RPC and a signalling system.

The latter is a popular system for UNIXoid desktops. It allows your application to export methods and signals for inbound and outbound communication respectively. If you have ever done GUI programming, you already know the concept of methods & signals. It is just like that, only across process and with some systems even network boundaries.

D-Bus can be used with a great variety of languages like C, C++, Python, C#, Ruby or Java. There is a Windows port too but I can't tell you how well it works. I'm sure some Windows-head can recommend a better solution. Maybe "MS .NET Remoting"?

Links:
- Inter-process communication - Wikipedia, the free encyclopedia
- freedesktop.org - Software/dbus
- winDBus | Get winDBus at SourceForge.net
- .NET Remoting - Wikipedia, the free encyclopedia

[Harland]

Thanks Sednogmah for your detailed reply While reading about D-Bus I stumbled across the CreateEvent method, which I believe I may be able to utilise via PInvoke in .Net. It appears to encompass the requirements for my particular scenario.

I haven't found any documented setbacks with such a setup besides the mention of security issues (which seems obvious, afterall I am breaking the application boundary). Other than that I believe it should improve synchronisation and concurrency issues in my current Shared Memory Library.

[Sednogmah]

I haven't found any documented setbacks with such a setup besides the mention of security issues (which seems obvious, afterall I am breaking the application boundary). Other than that I believe it should improve synchronisation and concurrency issues in my current Shared Memory Library.

On Linux it's solved with file system permissions. For example on the session bus, applications can only connect to apps of the same user. If you're talking about security in the sense of being detected by WoW/Warden, that's a different issue but I don't think it's a problem really.

.NET/C# D-Bus library: http://www.ndesk.org/DBusSharp
For C++ I'd recommend a wrapper like dbus-c++ instead of the plain C API because "If you use this low-level API directly, you're signing up for some pain." - it's true!

(Side note: This thread should be in the programming section, not memory editing. Maybe some mod can move it.)

[Harland]

Nah was just referring to the sense of system sense with application domains and what not. Not too worried about Warden right now, just having fun mucking around on Trial accounts.

Tomorrow I might look further into a dbus implementation, it appears to be the way to go.

And yes it was quite silly of me to post this thread here, my bad.

[ostapus]

for my experiments (with pathing) i was using c# server to receive commands from injected DLL via pipe ipc. easy to implement.

[amadmonk]

Pipes are, IMO, a nightmare. I posted a lengthy rant about them over on the elite section.

The problem I have with them is that they're technically a scarce commodity, so you have to carefully control their lifetime. In a normal application, this isn't a huge problem (although managing a multi-instance server pipe is still a pain).

The upside of pipes is that they are the fastest IPC that has a "pre-rolled" messaging framework on the same box (once you cross computer boundaries, other solutions become as fast or faster). On the same box, a pipe can push about 1GB/sec, which is far more data than you will EVER need. Even an extremely "chatty" controller/headless bot solution rarely uses more than 500Kb (kbits, in this case)/sec.

Remember that the lower-level the interface, the more you have to do. If you want an RPC pattern, you'll have to roll your own mechanism for call and response synchronization, including any locking and blocking issues.

You could also use sockets and custom serialization (what I'm doing in my headless bots). The performance of this is still quite high locally (I'm pushing ~500MB/sec), and if you use UDP, you don't have to worry about message framing (since UDP is message-oriented). With TCP, you gotta do it all. Of course, with any bare socket solution, you'll need to handle messages and any RPC you want.

One nice thing about UDP is the ability to multicast, which is awesome when you wanna send some data, but you don't know WHO you want to send it to. You can just sort of send out a "message in a bottle" and see if someone responds. Very handy!

On a higher level of abstraction, you have things like web services, remoting, and WCF. These are attractive because they "pre-roll" a lot of things you have to do by hand otherwise, such as messaging, RPC, and so on. However, there's a price -- they carry a significant overhead per call, they tend to be fragile in an embedded environment, and they are an absolute nightmare to debug, ESPECIALLY in an embedded environment. All of these limitations led me to abandon a service-oriented design.

Frankly, I'd recommend the solution I'm using right now: UDP with custom serialization.

I don't know enough about dbus to comment on it. Obviously, since it's a Unix thing, it's going to require Mono support or some other way for C# to "talk to" it.

[Sednogmah]

Amadmonk's warning about using large premade libraries is probably generally true. A large code base always comes with the risk of slow speed and fragility. KISS (Keep It Simple Stupid) is sometimes worth considering!

I don't know enough about dbus to comment on it. Obviously, since it's a Unix thing, it's going to require Mono support or some other way for C# to "talk to" it.

I haven't tried it but DBusSharp - NDesk claims that it runs on the plain Microsoft .NET runtime, without Mono.
Regarding the speed of D-Bus: Older benchmarks suggest that it's about 2-3x slower to push raw data over D-Bus than over a raw pipe even though pipes are naturally optimized on Unix-like systems because they are used a lot. A slowdown of 3x is still acceptable for the abstraction and language independency you get. If your bot needs to move 1 GB/s constantly, there's something horribly wrong anyway.

@OP: Good luck with your choice, mate. Please let us know how it worked out for you.

[Harland]

I ended up taking the approach which required a lot more work. I decided to write my own synchronisation framework which from tests so far appears to be working flawlessly. I'll need to load test it tonight and make sure it doesn't deadlock at all.

But if anyone is interested in utilising the Mapped Memory File Approach in C# Controller to a C++ DLL for IPC the Win32 API provided the following functions to make the magic happen:
- CreateFileMapping
- CreateMutex
- CreateEvent

Obviously this is not a complete list but MSDN will suggest related methods to allow for a section of memory to be allocated that is shared cross process, the locking of your memory structure, and signalling and event handling. Furthermore I do not promote this as being the only or best way to tackle IPC with Shared Memory.

At least I finally got to put some knowledge learnt in Systems Programming at Uni to work. I know most people would find it tedious and pointless writing their own framework, but it was a good experience for me nevertheless.

Thanks again to everyone who posted suggestions

[Flowerew]

You're probably refering to Interprocess Synchronization (Windows). So you create your file map, control access to it via the mutex and raise events to notify your processes if there's data to be shared...interessting.

If you would be so kind to eleborate a little on your method. Not the code or actual implementation itself but rather your concept. Do you process events as they occur or do you buffer events. If it's the later, how do you deal with the same and different types of message objects? Do you request data or do you have a constant stream of data or both? I'm just interested as to how others approach IPC.

[amadmonk]

Shared segments like this have an insanely high raw performance (probably on par with pipes locally, if not potentially a tad higher; pipes *use* shared memory locally, but there is a small tax for message boundaries and stuff).

It's not the solution I'd go with because it requires you to manage literally EVERYTHING manually -- buffers, in vs out vs duplex, framing, signaling, synchronization -- EVERYTHING. But I'll say this: once you have a working shared memory messaging system working (I did it once, sort of to understand the technology, many years back), you'll have a great appreciation of what even interfaces as low level as pipes and sockets can give you

[Harland]

If you would be so kind to eleborate a little on your method. Not the code or actual implementation itself but rather your concept. Do you process events as they occur or do you buffer events. If it's the later, how do you deal with the same and different types of message objects? Do you request data or do you have a constant stream of data or both? I'm just interested as to how others approach IPC.

Currently I am using the process as you go method. Eventually I would like to buffer my events, but I've got a busy schedule this week so I'll have to put this project aside.

My current implementation is that I have three generic custom classes, Mutex, Event, and SharedMemory. From there I build a fourth class which implements those three classes. I call this fourth class my DLLController. Basically it makes use of a structure which is imposed on the memory mapped file. Lets just say the following is my structure:

struct myStruct
{
//CTM
float x;
float y;
float z;
WGUID wGuid;
ClickToMoveType actionType;

//LuaString
byte luaString[512];

};

I then create a separate Mutex for the CTM and LuaString memory segments. Additionally I set up an Event for the aforementioned memory segments. So when the Controller wants to invoke a CTM action it must do the following:
- Obtain ownership to the CTM mutex
- Write the parameters
- Release the CTM mutex
- Signal the CTM Event

Meanwhile the DLL will carry out the following:
- Respond to the CTM signal unblocking the thread
- Obtain ownership to the CTM mutex
- Read the parameters
- Invoke CTM
- Release the CTM mutex
- Reset the CTM Event to unsignalled

The only issue I foresee is the consumer/producer anomaly whereby the producer pumps out way too many messages for the consume to handle. In my case there is the possibility that the previous message will be overwritten, hence why I need to implement a buffering mechanism eventually. I haven't replicated such a case yet, because my producer test wasn't sending messages fast enough I guess for the consumer to crash and burn. But no doubt it will happen.

Anyways I must be off.