Fieldpine Logo Documentation Home   DESIGN NOTES

This information is a technical design note. Use extreme caution if relying on this information, it may be outdated or incomplete

Design Note: Mesh Memory (lanes)


Mesh Memory on lane computers provides a networking and communication base for systems on that lane. Rather than all applications individually being configured and communicating with remote systems, a copy of Mesh Memory is run on each lane/server to handle the communication requirements.

Source Ref: MeshMemory (Agent\MeshMemory) and MeshLocal (Agent\MeshMemory\MeshLocal)

See Also: General Mesh Memory documentation

MeshLocal

MeshLocal.exe provides a local service or application to provide MeshMemory on a machine. MeshLocal can either be run as a service or interactive program. Other than handling service interaction it does little more than invoke MeshMemory.dll to actually provide the services

If MeshLocal is NOT being used then any other host program can be used to invoke MeshMemory.dll

MeshLocal does not require any special privileges other than the ability to create a NamedPipe and TCP/UDP sockets

MeshLocal calls into MeshMemory.dll and creates a thread that attempts to download the latest copy of meshmemory.dll, using SSL, once per day. If a new version is downloaded it is not used until the next restart of MeshLocal (Source: MeshMemory - UpdateThread() ) If a network error is encountered it will retry every hour until cleared.

MeshMemory.dll

  1. A number of listening threads are started to listen on a Named Pipe
  2. Each thread waits for an inbound request and then processes it
  3. The command is read from the Named Pipe, this be a valid GNAP format command packet
  4. If the command packet is "HVRB", execution is passed to the Http Verb handler. This permits MeshMemory to respond directly to HTTP requests.
  5. If the command packet is "CMDL", then the command packet is passed to correct memory, queue or table handler

How it is used

  1. On startup, every Fieldpine program creates an inbound QUEUE on the path /rma/RMSYSTEM/fgi/FINGERPRINT eg /rma/7,1,2,3/fgi/A34FE792A3E4E002334. This queue is created as a single class queue.
  2. This queue is created on the local machine if a mesh server is present (by checking the pipe exists), otherwise it is created on fieldpine web sites (if the site has enabled Fieldpine routing)
  3. Next, the site determines the current mesh TABLE name. This uses the encryption key and the address of this table changes every 24 hours. A sample address might be /rma/7,1,2,3/cdi/2379f92n40FH299284782vHF933J1Fbcwj24sh2824h2
  4. It polls fieldpine.com to retrieve it's public IP address (www.fieldpine.com/echo.js)
  5. It creates a packet describing the node and program, encrypts it, and inserts it into the mesh table
  6. If the site believes it cannot calculate the current mesh table, it sends a different packet, with much less information, to the queue /rma/7,1,2,3/oqi/OrphanQueue. This queue is not currently read, but may be used in future to regain connectivity under abnormal circumstances.
  7. The program monitors its inbound queue (created in step #1) and actions any valid commands received.