Analyzing the Architecture of Xunlei's Electron‑Based Desktop Client

The author, after exploring Feishu's source code, discovered that Xunlei's desktop client is also built on Electron, which makes its frontend resources readily accessible for analysis.

Electron packages local resources in an asar archive, often encrypted; however, Xunlei does not use asar for its client, so most JavaScript files are exposed directly.

By inserting a small script into the main‑renderer file, the author opened the developer tools and observed that the floating circular UI and the main window are each implemented with separate BrowserWindow instances, the former being roughly four times larger than the visible floating window.

The process tree shows that the entry executable Thunder.exe spawns an Electron main process, its renderer processes, and a separate DownloadSDKServer process. All Electron windows share the same main process, while the SDK runs as an external service.

Inter‑process communication (IPC) is not the standard Electron IPC; instead, the frontend builds its own IPC server ( __xdasIPCServerInstance ) in the main window, exposing a JavaScript API that proxies calls to the DownloadSDK.

Key API functions such as createTask are defined in the frontend code. A representative snippet is shown below:

<code>createTask(e, t) { return n(this, void 0, void 0, function* () { ... switch (e) { case h.DownloadKernel.TaskType.P2sp: ... case h.DownloadKernel.TaskType.Bt: ... case h.DownloadKernel.TaskType.Emule: ... case h.DownloadKernel.TaskType.Group: ... case h.DownloadKernel.TaskType.Magnet: ... default: i = !1; } ... _.fireTaskEvent(h.DownloadKernel.TaskEventType.TaskCreated, [ ... ]); }); }</code>

Further code reveals that the SDK is launched via a native Node.js addon ( ThunderHelper.node ), which executes the DownloadSDKServer.exe and communicates through a shared memory object (e.g., \Sessions\5\BaseNamedObjects\xx@22123720|SendShareMemory ).

The analysis concludes that Xunlei places heavy responsibilities on the frontend process—handling node addons, process management, and multi‑window communication—rather than delegating them to a dedicated backend, which may affect performance and maintainability.