MeshCentral/MeshAgent
1
0
Fork 0
mirror of https://github.com/Ylianst/MeshAgent synced 2026-02-18 02:19:02 +00:00
Code Issues Releases Wiki Activity

added new sections

Browse Source
This commit is contained in:
Bryan Roe
2022-09-07 23:40:41 -07:00
parent cbe178869b
commit 966300576e
1 changed files with 26 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
docs/Architecture.md
View File

@@ -40,7 +40,7 @@ agent would pretend to be an office computer to which administrator would login
username & password, especially when the root is not hardened. Some care should be taken to
protect the <20>meshagent.db<64> file and to not give important information to untrusted agents.
#### Agent to Server Handshake
#### Server Control Channel Handshake
One interesting aspect of MeshCentral<61>s design is how the agent connects to the server. We wanted a way for the agent to connect to the server that would be similar to how browsers
connect to web servers. This allows for a large number of agents to connect just like if a large number of browsers where connecting. All of the infrastructure that helps web server<65>s
scale would be put to use in the same way for agent connections. For example: TLS offload hardware, load balancers, reverse-proxies, web server scaling, etc. could all be put to use.
@@ -85,7 +85,7 @@ This can
rights on the agent, but the agent does not have any right on the server. This is important since the agent does not, by default, have any credentials to the server. Any agent can
connect to the server and claim to be part of a device group.
#### Browser to Agent Relay and WebRTC
#### Relay Tunnel Sessions and WebRTC
Browsers and agents often need to communicate to each other. Data sessions are used for desktop, terminal, file transfers, etc. and must be setup securely. To setup a session between
a browser and the agent, the server will send a URL to both sides to connect to. The URL is generated by the server and includes a unique connection token. It is sent to both the
@@ -127,6 +127,30 @@ is used to signal the end of the WebRTC session.
#### JavaScript Runtime
One of the biggest improvements to the Mesh Agent design, ws the incorporation of the Duktape Java Script Runtime. One of the design goals for Mesh Central, was to try to have the same code
running on the browser, the server, and the agent. This simplified design lowers complexity annd increases maintainability. While we could have used NodeJS on the Agent to match the Server,
this would have greatly increased the platform requirements. One of the main requirements for the agent, is that it can run on a wide gamut of devices and platforms, including embedded platforms
with limited resources. So we chose to implement the agent in C, and utilized Duktape, to expose a Node like JS environment. By exposing a NodeJS like interface, allows the developer to quickly
implement code on the agent using a familiar set of APIs, while at the same time, allowing the agent to require less resources than a traditional NodeJS implementation.
The agent itself is single threaded, but fully asynchronous. The main thread is often referred to as the Microstack Thread, or the event dispatch thread. The native C code is organized as
links on a chain. The dispatch thread enumerates all links on the chain to populate the descriptor table. The dispatch thread will then block on a system call until either a preset timeout elapses,
or one of the descriptors triggers. In optimal situations, the agent should spend a majority of its time blocked, waiting on the descriptors. This is considered idle. Ideally, the dispatch thread
would only unblock wheren there is work to be done.
Some operations, particularly on Windows, involve more than a single thread, such as the Windows Message Pump. For these types of operations, anytime a call is made back into the JavaScript engine,
the call is always dispatched back to event dispatch thread. The main design philosophy of all the Javascript code, is that everythign is event driven, whether it be accomplished by using an event
emitter or by using promises.
#### Agent Cores
By default when an agent starts up, the only thing it knows how to do, is to connect to the server. Once the Server Control Channel is connected and authenticated, the server will query the agent
for the hash of the Javascript that it is running. The Javascript that is running is referred to as a "core". This comes from the idea that the Javascript code that runs, forms the core operations
of the agent. The server can instruct the agent to clear it's "core", and it can send new "cores" to the agent to execute. The Node like APIs exposed by the agent, allows the "cores" to perform
almost anything on the agent. Some of the more interesting aspects of the JavaScript design, is that the cores can utilize a node like Foreign Function Interface (FFI) to be able to call native
functions, such as functions contained in stdlib, gdi+, x11, etc. Similarly, the cores can dispatch child processes, to take advantage of system utilities such as awkscript, etc. These are truly
powerful capabilities that allows for a rich set of operations that can be performed.
#### Native Update