DLL注入/ IPC問題

Question

我正在使用一個可啟動數千​​個進程（編譯，鏈接等）的構建工具。 它還將可執行文件分發到遠程計算機，以便可以跨100個從屬計算機運行該構建。 我正在實現DLL注入以監視構建過程的子進程，以便可以看到它們打開/關閉了我期望它們的資源。 這樣，我可以判斷用戶是否未正確指定依賴項信息。

我的問題是：

我已經完成了DLL注入的工作，但是我對Windows編程並不那么熟悉。 用子代將生成的數百萬個文件io報告，回調到父代構建過程的最佳/最快方法是什么？ 我曾考慮過讓它們寫入非阻塞套接字，但一直想知道也許管道/共享內存或COM會更好嗎？

Answer 1

如果您停留在Windows世界（您的機器都不是linux或其他機器）中，則命名管道是一個不錯的選擇，因為它速度很快並且可以跨機器邊界訪問。 我認為共享內存已經不合時宜了，因為它無法跨越計算機邊界。 分布式com允許在IDL中制定合同，但我認為通過管道的XML消息也可以。 xml消息的好處是可以完全獨立於通道工作。 如果您以后需要linux，則可以切換到tcp / ip傳輸並發送xml消息。

一些其他技術有局限性：

另一個被遺忘但熱門的候選人是RPC（遠程過程調用）。 許多Windows服務都依賴於此。 但我認為編寫RPC很難

如果您在同一台計算機上，並且只需要發送一些狀態信息，則可以通過RegisterWindowMessage（）注冊Windows消息，並發送消息vie SendMessage（）

Answer 2

首先，由於您顯然要處理機器之間的通信，而不僅僅是在一台機器內，因此我會立即排除共享內存。

我會努力嘗試盡量減少數據量，而不必擔心發送速度有多快。 我沒有發送數百萬個文件I / O報告，而是將幾千字節的數據（或按順序排列的東西）打包在一起，然后發送該數據包的哈希。 通過仔細選擇數據包大小，您應該能夠減少數據傳輸，以至於您可以簡單地使用您認為最方便的任何方法，而不是嘗試選擇最快的方法。

Answer 3

除了托馬斯提出的所有建議外，您可能還只是使用一個公共數據庫來存儲結果。 如果太慢，請使用更現代（更快速）的鍵/值數據庫之一（例如tokyo cabinet / memcachedb / etc）。

Answer 4

對於驗證構建中使用的文件的任務來說，這聽起來有些過高。 怎么樣，只掃描構建文件？ 或捕獲構建工具的輸出？