Goal
Run the hardware-emulator as a service. It creates a TCP server and listens on a given port.
The simulation can then connect to it using the TCPBackend class and use the TCP protocol to communicate. Simulation to Autopilot communication shows where the hardware_emulator_server lies in the overall simulation-autopilot setup possibilities.
Explicit "Suspend" Logic (USED)
Data-structures
- Session pool:
- Contains threads, "loaded" & "done" flags, communication buffer.
- Lives with every connection
- Holds an emulator while live
- ONLY WRITTEN AND READ BY THE SERVER THREAD (=> thread safe)
- Save hashmap:
- Stores "suspended" emulators using a random key
- Accessed by different session threads => Must be Thread synchronized
- mutex: handles access to "save" hashmap
Server Thread
- Listen for incoming connections.
- On New Connection:
- Gen new random session ID + check if nothing in data hash_map
- Get available Session slot (+clean old ones if needed).
- Start session thread with ID
Session Thread
- Wait for first packet:
- If INIT: load new emulator + init sequence
- If RECONNECT: Pull the emulator from the "save" hashmap + reconnect sequence
- Simulation cycles
- ERROR packet or END packet or disconnect:
- Delete emulator
- Free socket
- Set "done" flag
- Return
- SUSPEND packet:
- Save emulator at ID in "save" hashmap
- Free socket
- Set "done" flag
- Return
Implicit reconnect Server Logic (NOT USED)
The following shows the actions of the server on different events.
- On New TCP connection: Create new thread on
EmulatorSession::session().- On Disconnect:
- Set "freeing timer"
- Delete thread
- On
PACKET_INIT: Get new slot (ID) MAKE THREAD SAFE.- On
PACKET_RECONNECT:
- Reclaim slot MAKE THREAD SAFE.
- Cancel timer
- On Timer: Clear slot (memory).