Skip to content

Home

Jump to bottom
Herman Li edited this page Nov 20, 2020 · 6 revisions

Front End Specifications

Frameworks/Libraries Used

  • xterm.js
  • react

Commands Needed

  • ls
  • cat
  • rm
  • sbatch
  • scancel
  • squeue
  • Some sort of edit command for sbatch script files
  • date

Design

Terminal needs to be very similar to an actual terminal with a limited bash shell simulated because there is no way to put an actual bash shell in unless you directly connect to the server (which has multiple problems). Using limited commands it will need to sync up with server both the time and file structure. A text editor (separate and below the terminal) will be included to handle editing of batch script files because of the limited abilities to make a text editor built-in to the terminal simulation. All data to and from the server will be in JSON.

REST JSON Structure

{ "time": 0, "action": "edit config" "body": "config file text" }

Web Server Design/Approach

Frameworks/Libraries Used

  • cpp-httplib
  • wrench
  • nlohmann-json

Design

Front-end contains a map of files holding file structure and data. Any needed data to be transferred to and from the server will be contained here. (Though a copy of the map can be placed on the server as well and be updated on sync-ups) Due to Wrench and the web server will block the main thread, one of the two will need to run on a separate thread. As a separate issue, because SimGrid handles threads in its own special way, checking for next event cannot be triggered on a separate thread requiring a flag to check for events in the main loop thread.

The server is a standard REST server in C++ and needs to interact with Wrench (mostly handled by cpp-httplib)

  • Receives current time of client and will update and match the server's own clock.
  • Will send back the exact same time back to the client to guarantee the sync-up between client and server.
  • Format of message will be in json with the body containing time, action, and body (if needed) keys

Handling events with relation to Wrench:

  • The client will ping the server every second to sync between the client and server.
  • Any other interactions with the server will also trigger the sync.
  • These particular server syncs will also be used to update the wrench internal clock.
  • Using Wrench's waitForNextEvent with timeout of 0.01 until it reaches 1 second (or better to just set it to 1 sec?).
  • Collect the number of events and then send it back to client in a batch within the timespan.
  • If a job has finished successfully: my reply on the network will say something about .out and .err files generated.
  • If a large jump in time is executed (like jump ahead 1 hour), the piled up messages will be returned as a batch.
UI Time                     Simulated Time:
0                           0
100: sbatch                 100: do the sbatch (job would complete at 1000)
110: sbatch                 110: do the sbatch (job would complete at 10000)
2000: ls                    2000: need to check on pending jobs, and figure what happened and fake the output files
Clone this wiki locally