A simple fast IPC based on Windows Messaging

[Nine]

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]

..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]

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

[Gianni]

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

Edited May 1, 2020 by Chimp

[argumentum]

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]

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

[Bilgus]

but I can be with a bit moar work..

[water]

Added to the wiki

[Nine]

New version available :

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

[seadoggie01]

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]

@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]

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]

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]

@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]

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

[VAN0]

Thank you for this UDF.

One question though, does this UDF relies on tray icon and it's events? Why does it have this:

Opt("TrayOnEventMode", 1)
  Opt("TrayMenuMode", 1)
  Opt("TrayAutoPause", 0)
  TraySetIcon("shell32.dll", 300)
  TraySetOnEvent($TRAY_EVENT_PRIMARYUP, __WCD_Exit)
  TraySetState($TRAY_ICONSTATE_SHOW)
  TraySetToolTip("Left click to Exit WCD Server")

Unless this is required somehow, this should be handled by the script, not UDF...Simple exiting script should never be done by UDF, because script might require it's own cleaning up on exit.

[Nine]

I understand your arguments and they are quite valid.  I wanted to offer an easy way to exit the server, and a check if there are still messages waiting in queue. But this can be made optional if need be.  Meanwhile, If you want to clean up your server script, you can use OnAutoItExitRegister (as you probably know)

[VAN0]

Another suggestion if I may. To allow use this UDF in multiple applications on the same machine, perhaps the server name could be supplied as an argument to the _WCD_CreateServer().

This will also allow create a more secure link between two instances of the same script (i.e. using Multi-task udf) by generating random server name, or run two servers for a true 2-way communication.

[Nine]

Doable, in fact it is quite simple to implement.  But it would create a large breach in the security of the UDF. 

Let's say one decides to create multiple servers in a single script.  Then all servers would share the same queue, the same handler, the same thread.  Not brilliant, but it would make it possible to do.

As the title says, I want to make it simple, so anyone with little knowledge of IPC can use it.

[VAN0]

Not sure what security breach you are referring to...if nothing else, it would make it more secure since outside applications won't be able send messages to static WCDServer server.

Having multiple servers in the same instance of the script doesn't make sense to begin with...I was referring to running the same script as separate processes on the same machine.

To make this possible in current UDF all it needs is make $WCD_SERVER_WINDOW_NAME as non-constant variable (so it can be set by the script) and use it in _singleton (?)