A simple fast IPC based on Windows Messaging

[Nine 1,608]

After seeing a number of threads talking about how to exchange efficiently messages between processes (Inter Process Communication), I decided to create a framework using Windows Messages WM_COPYDATA.  What is new with this UDF you ask ?  Well it will depends how familiar you are with IPC.  One thing is sure, the simplicity of use and the fabulous speed are amazing.

This is based on a Clients-Server approach.  You can have an unlimited number of clients talking with a single server.  You will have to define the protocol of communication between them, but the code you have to create is incredibly low. The UDF proposes 2 simple message properties of communication.  The first (called data) is based on a number.  You can decide what value 1,2,3, etc. means between your client and server.  Server will react upon the value of the data field.  Second, there is a string field where you can inscribe additional information on request, and where the server will respond to client request (if necessary).

Here are the functions that I have wrapped around this :

Func _WCD_CreateServer 
Func _WCD_CreateClient 
Func _WCD_GetServerHandle 
Func _WCD_IsServerAvailable 
Func _WCD_Send
Func _WCD_WM_COPYDATA_CLIENT_HANDLER
Func _WCD_Client_GetResponse 
Func _WCD_WM_COPYDATA_SERVER_HANDLER
Func _WCD_Server_PeekRequest 
Func _WCD_Server_GetRequest 
Func _WCD_Server_IsRequestAvail 
 

Here an example of the server :

#include <Constants.au3>
#include <GUIConstants.au3>
#include "WCD_IPC.au3"

Opt ("MustDeclareVars", 1)

$_WCD_Verbose = False ; make it True if you want to follow the convos.  False is by default.

Local $hServer = _WCD_CreateServer ()
Local $aReq, $iData

While True
  If _WCD_Server_IsRequestAvail () Then
    $aReq = _WCD_Server_GetRequest ()
    $iData = @extended
    Switch $iData
      Case 1  ; who are you
        _WCD_Send($hServer, $aReq[0], $iData, @ComputerName)
      Case 2
        Switch Number($aReq[1])
          Case 1
            _WCD_Send($hServer, $aReq[0], $iData, @IPAddress1)
          Case 2
            _WCD_Send($hServer, $aReq[0], $iData, @IPAddress2)
          Case 3
            _WCD_Send($hServer, $aReq[0], $iData, @IPAddress3)
          Case 4
            _WCD_Send($hServer, $aReq[0], $iData, @IPAddress4)
          Case Else
            _WCD_Send($hServer, $aReq[0], $iData, "Invalid parameter")
        EndSwitch
    EndSwitch
  EndIf
  Sleep (100)
WEnd

And the client :

#include <Constants.au3>
#include <GUIConstants.au3>
#include "WCD_IPC.au3"

Opt ("MustDeclareVars", 1)

$_WCD_Verbose = True ; as for the server, you can decide to make client verbose or not
Global $hWnd = _WCD_CreateClient ("Test WCD Client")
Global $hWndServer = _WCD_GetServerHandle ()

_WCD_Send($hWnd, $hWndServer, 1) ; simple request - who are you ?
Local $sString = WaitForResponse ()
ConsoleWrite ($sString & @CRLF)
_WCD_Send($hWnd, $hWndServer, 2, "5") ; adding text to a more complex request
$sString = WaitForResponse ()
ConsoleWrite ($sString & @CRLF)

Func WaitForResponse ()
  Local $sResp
  While _WCD_IsServerAvailable ()
    $sResp = _WCD_Client_GetResponse ()
    If $sResp <> "" Then Return $sResp
    Sleep (100)
  WEnd
EndFunc

As always, let me know if you got issues, comments, suggestions.  I will be glad to answer.

Version 2020-06-27

* Allows processes with different levels of privilege to communicate with each other

 

 

WCD_IPC.au3

Edited June 27, 2020 by Nine

[argumentum 910]

..at a same level of execution ( user - user, admin - admin ), this approach is good but otherwise ( user - admin ), it won't communicate as is. Tested just now.

[Nine 1,608]

@argumentum Out of curiosity, just how exactly did you do your test between user-admin ?

[Gianni 846]

... I suppose by placing a #RequireAdmin on one of the scripts (?)

Edited May 1, 2020 by Chimp

[argumentum 910]

8 hours ago, Nine said:

Out of curiosity, just how exactly did you do your test between user-admin ?

to quote @Chimp, "by placing a #RequireAdmin on one of the scripts"  

[Nine 1,608]

I see.  Oh well, que sera sera.  Anyway, it was not intended for a mix of credentials.

[Bilgus 168]

but I can be with a bit moar work..

[water 2,703]

Added to the wiki

[Nine 1,608]

New version available :

As per @argumentum suggestion, I added IPC between different levels of execution

[seadoggie01 301]

I was hoping to use this UDF, but the example server and client don't communicate for me. I added some ConsoleWrites to the client and found it does one of 3 things:

* it will wait in the '_WCD_IsServerAvailable' loop forever waiting for the server to be available
* it will find the server repeatedly but receive no response
* the client will crash AutoIt with "AutoIt3.exe ended.rc:-1073740771" (it continues even after adding a global COM error handler)

I'm running on Windows 10 Enterprise 21H2 and both scripts are run without admin permissions. Do you know if it's possible that this feature could be blocked?

[Nine 1,608]

@seadoggie01  I am unable to reproduce your error.  Tested on Win10 home edition 21H1 with the example I provided.  I tested all scenarios with and without #RequireAdmin, no issue.  Could you describe exactly what you are doing ?

22 minutes ago, seadoggie01 said:

Do you know if it's possible that this feature could be blocked?

I don't understand your question.

[seadoggie01 301]

I slightly modified the WaitForResponse function to add some ConsoleWrite statements and added a global error handler at the top of the script

Global $oErrFunc = ObjEvent("AutoIt.Error", "ErrFunc")

; [...]

Func WaitForResponse ()
  Local $sResp
  ConsoleWrite("Waiting for server" & @CRLF)
  While _WCD_IsServerAvailable ()
    ConsoleWrite("Server is available!" & @CRLF)
    $sResp = _WCD_Client_GetResponse ()
    If $sResp <> "" Then Return $sResp
    Sleep (100)
  WEnd
EndFunc

Func ErrFunc($oError)
    MsgBox($MB_OK, "We intercepted a COM Error !", _
            "Number: 0x" & Hex($oError.number, 8) & @CRLF & _
            "Description: " & $oError.windescription & _
            "At line: " & $oError.scriptline)
EndFunc   ;==>ErrFunc

Then I run the server file from the command line and started the client from SciTE.

By "Do you know if this feature could be blocked?" I mean, I'm in a heavily locked down work environment and was wondering if it's possible that this form of communication could be blocked by some program/policy/etc by IT for security concerns.

[Nine 1,608]

The COM handler is useless since the UDF is solely based on Windows Messaging System.  I do not use any COM object in my code.  Nothing is mentioned in MSDN about blocking this message, but I am not an expert about security, so in other words, I don't know.  However, I am sure that your security guys can answer this question.  One thing you could try is to put both client and server in verbose mode :

$_WCD_Verbose = True

Log is in WCD_Logfile.log.  Before starting delete this file if it already exists.

[Nine 1,608]

@seadoggie01

You could try to force the message to be allowed by putting this at the beginning of both client and server script :

If Not _WinAPI_ChangeWindowMessageFilterEx(0, $WM_COPYDATA, $MSGFLT_ALLOW) Then Exit MsgBox(0, "Error", "Unable to allow message")

 

[seadoggie01 301]

Sorry for the delay, another project came up at work. With that added line, both scripts ran and I got the same results. I'll try testing this at home to see if I can reproduce or if it's related to my work environment. Hopefully I'll update this soon! Thanks for the help either way!

Edit: Finally tested at home and it works fine. It seems it's related to my work environment, darn, another great script I can't use 😐

Edited March 7, 2022 by seadoggie01