This one works!!

Dockerfile

@@ -18,9 +18,14 @@ RUN go build -o /discon-server discon-wrapper/discon-server
 # Create the final image
 FROM ubuntu:24.04
 
-# Install runtime dependencies
+# Install runtime dependencies including C, C++, and Fortran libraries
 RUN apt-get update && apt-get install -y \
     libc6 \
+    libstdc++6 \
+    libgcc-s1 \
+    libgfortran5 \
+    liblapack3 \
+    libblas3 \
     && rm -rf /var/lib/apt/lists/*
 
 # Copy the binary from the build stage

README.md

@@ -24,7 +24,12 @@ There's not a lot to configure, but you're bridging two applications, so things
 
 ### Server
 
-Download `discon-server_386.exe` from [Releases](https://github.com/deslaughter/discon-wrapper/releases) and put it in the same directory as the Controller shared library. Start the server from the command line by running `discon-server_amd64.exe --port=8080 --debug`. The `port` argument specifies which port on your computer it will listen to for client connections. This can be any 4-5 digit number that is not already in use by the operating system. If it returns an error, try a different number. The `debug` argument enables debug output which will be helpful for checking that it's working, but should be turned off when running simulations. 
+Download `discon-server_386.exe` from [Releases](https://github.com/deslaughter/discon-wrapper/releases) and put it in the same directory as the Controller shared library. Start the server from the command line by running `discon-server_amd64.exe --port=8080 --debug=1`. The `port` argument specifies which port on your computer it will listen to for client connections. This can be any 4-5 digit number that is not already in use by the operating system. If it returns an error, try a different number. 
+
+The `debug` argument now accepts a level (0, 1, or 2):
+- `0`: No debug output (default)
+- `1`: Basic debug information
+- `2`: Verbose debug output including full payloads
 
 That's it for the server configuration. It doesn't load the controller until the client makes a connection because the client has to tell it what to load, more on that in the next section. 
 
@@ -56,19 +61,38 @@ set DISCON_CLIENT_DEBUG=1
 openfast.exe my_turbine.fst
 ```
 
-- `DISCON_SERVER_ADDR` describes the host and port the server is listening on. `localhost` indicates the same machine and the port, `8080`, needs to match the number that was given to the server via the `--port` argument.
+- `DISCON_SERVER_ADDR` describes the server address in one of these formats:
+  - `hostname:port` (e.g. `localhost:8080`) - Standard WebSocket connection
+  - `domain.name` (e.g. `controller.company.com`) - For use with reverse proxies that handle the port internally
+  - `http://domain.name` - Explicit HTTP protocol, uses WebSocket (ws://)
+  - `https://domain.name` - Secure HTTPS protocol, uses secure WebSocket (wss://)
 - `DISCON_LIB_PATH` is the path from `discon-server_386.exe` to the controller shared library.
 - `DISCON_LIB_PROC` is the procedure which will be called in the controller shared library.
 - `DISCON_CLIENT_DEBUG` is used to enable debugging output on the client side, messages will be printed to the terminal.
 
 You can see that the environment variable settings correspond to the original controller settings that were in the ServoDyn input file.
 
+## Client-Side Input Files
+
+DISCON-Wrapper now supports input files located on the client side. When a controller asks for an input file (such as DISCON.IN), the client will:
+
+1. Check if the file exists locally
+2. If found, automatically transfer the file to the server before the controller is called
+3. Update the file path that's passed to the controller on the server side
+
+This means you can now keep your input files on the client machine and don't need to manually copy them to the server. The file transfer happens automatically and transparently.
+
+Benefits:
+- No need to copy input files to the server
+- Files are transferred only once during a simulation
+- Files are automatically cleaned up when the connection closes
+
 ## Running
 
 For simplicity, put the OpenFAST input files, controller shared library, `discon-server_386.exe`, and `discon-client_amd64.dll` into a directory. Open two command prompts, one for running the server, and the other for running OpenFAST. Start the server by running the following in one command prompt
 
 ```
-discon-server_amd64.exe --port=8080 --debug
+discon-server_amd64.exe --port=8080 --debug=1
 ```
 
 Switch to the second command prompt, specify the environment variables, and run OpenFAST:
@@ -83,4 +107,4 @@ openfast.exe my_turbine.fst
 
 If everything is configured properly, the simulation should proceed as though OpenFAST had loaded the controller directly. Remember, that the server must be started before running the simulation because the client will attempt to connect when it is loaded. Once the simulation stops, the client will disconnect. The server is will continue running and wait for new connections so you can run more simulations. To stop the server, switch to the command prompt, and close it or press `CTRL+C` to kill the server.
 
-You may see a temporary copy of the controller while the simulation is running. This is done so the server can load multiple copies of the controller at once, supporting multiple concurrent OpenFAST simulations. If they aren't automatically removed by the server, they can be deleted manually once the server has been stopped.
+You may see temporary files created while the simulation is running. These include a copy of the controller and any transferred input files. They are automatically cleaned up when the connection closes, but if they aren't removed for some reason, they can be deleted manually once the server has been stopped.