प्रक्रियाओं के बीच IPC संचार

ipcMain.handle मुख्य प्रक्रिया में एक नामित चैनल पंजीकृत करता है, जो रेंडरर के अनुरोधों का उत्तर देता है। यह एक असिंक्रोनस हैंडलर फ़ंक्शन स्वीकार करता है और उसका लौटाया गया मान रेंडरर में Promise का हल किया गया मान बन जाता है। इसलिए यह फ़ाइलें पढ़ने या डेटाबेस से जानकारी प्राप्त करने जैसे कार्यों के लिए उपयुक्त है।

ipcRenderer.invoke किसी नामित चैनल पर संदेश भेजता है और एक Promise लौटाता है, जो मुख्य प्रक्रिया के हैंडलर के लौटाए गए मान के साथ हल होता है। इससे एक साफ़ असिंक्रोनस अनुरोध-उत्तर पैटर्न बनता है, जो प्रीलोड स्क्रिप्ट और रिएक्ट घटकों, दोनों में async/await के साथ स्वाभाविक रूप से काम करता है।

प्रीलोड स्क्रिप्ट ipcRenderer.invoke कॉल को लपेटती है और उन्हें contextBridge के ज़रिए उजागर करती है। उदाहरण के लिए: api.readFile = (filePath) => ipcRenderer.invoke('read-file', filePath)। रेंडरर window.api.readFile(path) कॉल करता है और उसे Promise वापस मिलता है — साफ़ और सैंडबॉक्स में सुरक्षित।

contextIsolation सक्षम होने पर रेंडरर प्रक्रिया require('electron') नहीं कर सकती और ipcRenderer को सीधे इंपोर्ट नहीं कर सकती — मॉड्यूल उसके लिए उपलब्ध ही नहीं होता। सभी IPC संचार प्रीलोड स्क्रिप्ट के contextBridge एक्सपोज़र के ज़रिए होना चाहिए। यह जानबूझकर किया गया है: इससे XSS हमलों को IPC तक पहुँच प्राप्त करने से रोका जाता है।

ipcMain.on, ipcRenderer.send से भेजे गए एकतरफ़ा संदेशों को सुनता है, invoke से भेजे गए संदेशों को नहीं। इसमें कोई स्वचालित उत्तर चैनल नहीं होता। यह पैटर्न उन सूचनाओं या कमांड के लिए उपयुक्त है जिनमें रेंडरर को उत्तर की आवश्यकता नहीं होती, जैसे घटनाओं का लॉग दर्ज करना या नेटिव सूचना दिखाना।

मुख्य प्रक्रिया webContents.send('channel-name', data) का उपयोग करके रेंडरर को डेटा भेज सकती है। मुख्य प्रक्रिया द्वारा संचार शुरू करने का यह प्राथमिक तरीका है — उदाहरण के लिए, फ़ाइल प्रणाली की निगरानी से मिली घटनाओं या नेटिव मेनू की क्रियाओं को रिएक्ट यूआई तक पहुँचाना।

प्रीलोड स्क्रिप्ट में, ipcRenderer.on('update', callback) मुख्य प्रक्रिया से आने वाले पुश संदेशों के लिए एक लिसनर पंजीकृत करता है। कॉलबैक को मुख्य प्रक्रिया द्वारा भेजा गया इवेंट और कोई भी डेटा प्राप्त होता है, जिसे आप फिर contextBridge के माध्यम से उपलब्ध कराए गए फ़ंक्शन से रेंडरर तक पहुँचाते हैं।

पुश इवेंट के लिए एक साफ़-सुथरा पैटर्न यह है: api.onUpdate = (callback) => ipcRenderer.on('update', (_event, data) => callback(data)). React घटक window.api.onUpdate(setData) को कॉल करके सदस्यता लेते हैं, और मुख्य प्रक्रिया द्वारा नया डेटा भेजे जाने पर कॉलबैक स्थिति को अपडेट करता है।

मेमोरी लीक और डुप्लिकेट कॉलबैक को रोकने के लिए, जब किसी ipcRenderer.on लिसनर की ज़रूरत न रहे तो उसे हटा देना चाहिए। प्रीलोड फ़ंक्शन को एक सफ़ाई फ़ंक्शन लौटाना चाहिए, जैसे () => ipcRenderer.removeListener('update', callback), जिसे React useEffect की सफ़ाई के लिए लौटाए गए फ़ंक्शन से कॉल करता है।

रेंडरर से आने वाले IPC इनपुट को मुख्य प्रक्रिया के हैंडलर में अविश्वसनीय डेटा मानकर चलना चाहिए। फ़ाइल पथों का हमेशा सत्यापन करें, ताकि पथ-उल्लंघन हमलों को रोका जा सके, क्वेरी पैरामीटर को स्वच्छ करें और जाँचें कि प्रेषक का मूल स्रोत अपेक्षित है। कभी भी कोई सामान्य eval या exec IPC चैनल उपलब्ध न कराएँ।

जैसे-जैसे आपका ऐप बढ़ता है, IPC चैनलों को नाम-क्षेत्र की परंपराओं के अनुसार व्यवस्थित करें: 'fs:read-file', 'db:query', 'window:minimize'। टाइपो रोकने और पुनर्संरचना को सुरक्षित बनाने के लिए चैनल नामों को एक साझा स्थिरांक वाली फ़ाइल में रखें, जिसे main.js और प्रीलोड स्क्रिप्ट दोनों में आयात किया जाए।

IPC, Electron संचार की रीढ़ है। ipcMain.handle और ipcRenderer.invoke, रेंडरर द्वारा शुरू किए गए कार्यों के लिए Promise-आधारित अनुरोध-प्रतिक्रिया जोड़ी बनाते हैं। मुख्य प्रक्रिया द्वारा शुरू किए गए पुश संदेशों के लिए webContents.send और ipcRenderer.on मिलकर काम करते हैं। रेंडरर में होने वाले सभी IPC संचार को प्रीलोड के contextBridge के माध्यम से भेजना चाहिए, और मेमोरी लीक रोकने के लिए लिसनर को हमेशा साफ़ कर देना चाहिए।