So they can easily be managed with rc GERTiMNC start/stop
This also provides autostart

Heres an example I made from GERTiMNC.lua, place it in /etc/rc.d/ and run rc GERTiMNC enable to have it autostart. (You still have to type rc right now after boot, it seams GERTiMNC doesn't like being run by the first rc pass at boot)

GERTiMNC.txt

Use kernel optimizations to non-busy wait for sockets to contain data.

Currently, processing a command must involve the whole command or no command. DoS is protected against by a timeout but chunked messages are still not handled well. This needs to change.

Create GERTi and GERTe translation gateway. Used for contacted GERTe Servers and other GERTe Gateways.

Implement "tunnels" or "subconnections" to optimize out the addresses of targets with smaller values.
See experimental branch for an early implementation

Joint test between GERTi and GERTe

For some reason on some windows machines (see #82) the QueueUserAPC seems ineffective at forcing threads to interrupt and become joinable. Linux also occasionally throws a fit, possibly due to updating, but it is not as bad as this.

Since both platforms have some annoying behavior, one recommended safety-net is a timer that force-kills the threads using pthread cancellation or killing, and windows TerminateThread. Alternatively just detach. Detaching is probably not great because these threads are likely to wait forever and not appropriately release resources as a result.

Public request to help port (or otherwise add support) to Windows.
This could be a little bit of rework as the system uses custom signals and various Unix specific functions to efficiently operate.

Review GENS Name Resolution Release Candidate 1 commit ca3a09

Documentation is included within the review. Check for typos and hard to understand portions.

Initial code created, awaiting debugging for publish. No optimizations added. Protocol is... questionable.

I formally request the number 867-5309, I have no idea what I'll do with it, but I want it.

Redo statuses such as having the FAILURE state persist after a command. FAILURE as a state was previously used the way it was due to how GEDS was coded but is now not needed.

Processor thread wakes up for no apparent reason when a gateway connects.

Odd behavior within CryptoError on some windows machines. My laptop has this issue but my desktop does not.

This issue may be either CryptoError somehow returning despite [[no_return]] or odd behavior with the thrown exception.

Neither should be a problem. CryptoError always throws and cannot return, so if it returns, that is an installation specific bug. If the thrown exception is not caught, then that is another installation specific bug because it is definitely within a try/catch.

More investigation will be needed, especially since my debugger is limited on that platform.

P.S. If the community will offer their machines, it may help track down the root cause.

Finished initial code. Optimizations to do. Also probably some protocol edits as GERTi expands.

Linux GEDS servers crash on a gateway registrations. The issue has been pushed back but still persist (specifically in Poll::add due to sock existing in the epoll context for some reason)

It is outdated and in places incorrect

GERTe API seems to be unable to read peers.geds correctly (or at least crashes when trying to connect.)

In progress

When cleaning up during closing, peers seem to crash the program (specifically closed peers.) Ultimately this should be fine as long as the remote end handles it well but produces a lot of unneeded log messages on close.

When debugging, casting a SIGINT which interrupts the process can cause a SIGSEGV despite GEDS not receiving the SIGINT.

Despite being defined in the protocol, the NodeJS and Lua APIs do not have means of accessing the encryption features.

Rewriting GERTe to better suit needs. GEPS was becoming clunky and GENS basically pointless. Combined them into GEDS and drafting.

Proposal

What is it

WiMNC would be a just very simple addition to how GERTi MNC works. It's made to be very simple, but also useful to RP servers, OC tablets, wireless GERT communication, etc.
Please note that as WiMNC is made for wireless communication, it doesn't respect clause B of GERTi Backend, therefore it should be optional.
WiMNC allows the user to select what MNC server to connect to, and also adds a protection layer compared to the actual connection method, however it can removes the automatic connection feature so the best would be that if GERTi API isn't provided arguments at import (maybe using dofile), it would keep the original connection mechanism, else it would use WiMNC, or allow the OS to manage it, for user interactivity, for example on openos a wimnc command

Basic information

A WiMNC broadcast is sent every 10 seconds containing information about the MNC. This feature IS optional (as it is not applicable for wired networks)

Communication

When broadcastings are sent through default OC modem port 32594.

Specifications

All packets are sent through port 32594!

WiMNC broadcast packet

The packet format is: a String containing the component ID of modem (for connection), a String containing the name of the WiMNC (can be anything, may default to "WiMNC Broadcast"), and a String containing the protection method (see below for values)

Protection methods

This proposal only specifies one protection methods and leaves the rest to the GERT maintainers. The method of encryption is not defined. The client authenticates using a password by sending a password validation packet. If after 1 second the server doesn't respond, the client will abort the authentication. This proposal also specifies an "unprotected" mechanism which requires no authentication.

Password validation packet

The password validation packet is just a string containing the SHA256 of password. As it is used for validation, the hash SHOULD NOT be used as key for encryption, so that since a hash is almost impossible to reverse-engineer, it would be secure.
The WiMNC-capable MNC will respond by a packet containing a boolean. True if password is correct, False if password is uncorrect.

Build the peer web after fully initializing and running the processor to allow connections before finished. This will speed up startup to become near instant with connectivity being the only slow part.

Reduce peering overhead (while introducing minor latency) by implementing "heavy peers" which create a "hub and spoke" web instead reducing the total number of open connections. Currently not important but will greatly improved scalability.

Current version of the GERTe protocol allows a replay attack within 60s (default.) Determine some way to fix that, such as a counter or a nonce? Also probably remember last seen timestamp.

Even on a GERTData event, reading socket always return an empty table. Even when doing a loop that only exists when the returned table length is not 0. The loop never ends (meaning it NEVER receives the data). Only messages doesn't work, connection to MNC is ok, socket connection OK, socket accepted OK, but socket messages not ok. Fix it ASAP please, as GERT is literally not usable without socket messages.
GERT Version is: 1.1.1 (latest)

When peering, specific when the remote is building the initial web, the remote peer appears to double accept the connection, successfully negotiating the first time, and hard crashing the second time.

Do a live test of GEDS server to ensure it functions. A second GEDS server may be temporarily set up to test GEDS-to-GEDS testing.