Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/zahi1/multi-protocol-system-integration

Multi-protocol system integration of a gas‑pressure simulation with interoperable Container, Input, and Output components joined via adapters. Server uses SimpleRPC; Input client uses gRPC; Output client uses RESTful HTTP; adapters unify calls into a single RPC-style domain interface.
https://github.com/zahi1/multi-protocol-system-integration

adapters-layer client-server csharp distributed-systems dotnet grpc interoperability microservices multi-protocol nlog nswag rabbitmq restful-api rpc simple-rpc simulation

Last synced: about 1 month ago
JSON representation

Multi-protocol system integration of a gas‑pressure simulation with interoperable Container, Input, and Output components joined via adapters. Server uses SimpleRPC; Input client uses gRPC; Output client uses RESTful HTTP; adapters unify calls into a single RPC-style domain interface.

Awesome Lists containing this project

README 

          
# Multi-Protocol Distributed System with Adapters for an Interoperable Networked Architecture



A systems interoperability project that simulates gas pressure in a container and integrates three independently networked components into a single cohesive system via adapters: the container server exposes a **SimpleRPC** endpoint; the input client communicates via **gRPC** (through the input adapter); and the output client communicates via **RESTful HTTP** (through the output adapter).



Short description: An interoperability system that simulates gas pressure in a container by coordinating three independently networked components (Container, Input, Output) through adapters. Each component uses a different communication style, while adapters provide a uniform RPC-style boundary so original components remain unmodified.



Core idea: Pressure depends on gas mass and temperature. Every 2 seconds, the container changes its internal temperature by a random amount. When pressure is below a lower limit, input components increase mass. When pressure is above an upper limit, output components decrease mass. If pressure goes outside the safe range (implosion/explosion), the container is destroyed and the simulation is reset. Input components are not allowed to add mass if pressure is above the lower limit, and output components are not allowed to remove mass if pressure is below the upper limit.



- Container (server): owns the canonical state (mass, temperature, pressure) and applies autonomous temperature changes every 2 seconds.

- Input component: increases mass when pressure is below the configured lower limit.

- Output component: decreases mass when pressure is above the configured upper limit.

- Adapters: provide a uniform RPC-style boundary so each component can keep its own communication style without being modified.



No dependencies were altered in legacy components; only addresses were configured where needed.



## Project goals



- Keep original components intact (no code changes, except addresses).

- Integrate differently networked components in one system using adapters.

- Ensure the system is free of race conditions, deadlocks, and livelocks.

- Use RPC-style wrappers in the adaptation layer.



## Concept overview



- Pressure is proportional to mass and temperature.

- Every 2 seconds, the container adjusts its internal temperature by a random value and checks safety limits.

- If pressure < lower limit: input increases mass (random positive amount).

- If pressure > upper limit: output decreases mass (random positive amount).

- If pressure drops below implosion limit or rises above explosion limit: the container is destroyed and automatically reset to initial state; input/output pause until safe again.



## Project structure / architecture



- InteroperabilityGasPressure/

  - `GasContainerLogic.cs` — thread-safe state and rules (temperature loop, pressure calc, limits, reset)

  - `GasContainerService.cs` — RPC-facing service implementing the domain interface

  - `Server.cs` — hosts the container service on localhost:5000

- GasPressureContract/

  - `IGasContainerService.cs` — contract defining IncreaseMass, DecreaseMass, GetPressure, IsDestroyed

- Adapters/

  - `Server.cs` — hosts an adapter on localhost:5002

  - `GasContainerService.cs` — bridges calls from the adapter to the container service through RPC-style proxy

- Input/

  - `Client.cs` — connects to the adapter and periodically requests mass increase while pressure is below the lower limit

- OutputAdapter/

  - `Server.cs` — hosts a controller-based adapter on localhost:5001

  - `Controllers/GasPressureController.cs` — exposes controller actions and forwards to RPC-style proxy

- Output/

  - `Client.cs` — connects to the controller-based adapter and requests mass decrease while pressure is above the upper limit



Data flow:

1. Container runs and updates temperature every 2s, enforcing limits.

2. Input queries pressure and requests mass increase when allowed.

3. Output queries pressure and requests mass decrease when allowed.

4. Both Input and Output talk to adapters, which forward to the domain service via a uniform RPC-style boundary.



## Technologies used



- Container (server): SimpleRPC endpoint that exposes the domain interface (`IGasContainerService`) at http://127.0.0.1:5000/gasrpc.

- Input side:

  - Input Adapter: gRPC service listening on http://127.0.0.1:5002; forwards each request to the container via a SimpleRPC proxy.

  - Input Client: gRPC client (see `Input/Client.cs`) that connects to the Input Adapter and requests mass increase when pressure is below the lower limit.

- Output side:

  - Output Adapter: Controller-based web endpoint on http://127.0.0.1:5001; forwards calls to the container via a SimpleRPC proxy.

  - Output Client: RESTful HTTP client (generated client in `Output/OutputClient.cs` used by `Output/Client.cs`) that calls the Output Adapter to decrease mass when pressure is above the upper limit.



Note on message queues: This version integrates components via request/response endpoints. A message-queue variant (e.g., RabbitMQ) can be added as a decoupled event or command path if you want asynchronous buffering, retries, or fan-out, but it isn’t required for the current flow.



## How communication happens (high-level)



- Each component uses its own preferred client/server style.

- Adapters sit in front of the container’s domain service and translate client requests to a common RPC-style interface (`IGasContainerService`).

- The domain service applies thread-safe updates and returns the current pressure and container status.



### How the adapters work



- Input Adapter (gRPC):

  1) Receives Increase/Decrease/Get/IsDestroyed calls from the Input client via gRPC.

  2) Forwards each call to the container’s SimpleRPC endpoint using a typed proxy of `IGasContainerService`.

  3) Returns the response to the gRPC client.



- Output Adapter (Controller-based):

  1) Exposes HTTP endpoints: `/increaseMass`, `/decreaseMass`, `/getPressure`, `/isContainerDestroyed`.

  2) Forwards each HTTP request to the container’s SimpleRPC endpoint using the same typed proxy.

  3) Returns the result to the HTTP client.



## Run locally



Prerequisites:

- .NET SDK 8.x installed



### Ports used

- Container service: 5000

- Controller-based adapter: 5001

- Adapter for input: 5002



### macOS (zsh)



1) Build the solution



```

 dotnet build InteroperabilityGasPressure.sln

```



2) Start processes in separate terminals (order matters)



- Container (domain service)

```

 dotnet run --project InteroperabilityGasPressure/GasPressure.csproj

```



- Controller-based adapter

```

 dotnet run --project OutputAdapter/OutputAdapter.csproj

```



- Adapter for input

```

 dotnet run --project Adapters/InputAdapter.csproj

```



- Input client

```

 dotnet run --project Input/Input.csproj

```



- Output client

```

 dotnet run --project Output/Output.csproj

```



### Windows (PowerShell or CMD)



1) Build the solution



```

 dotnet build InteroperabilityGasPressure.sln

```



2) Start processes in separate terminals (order matters)



- Container (domain service)

```

 dotnet run --project InteroperabilityGasPressure/GasPressure.csproj

```



- Controller-based adapter

```

 dotnet run --project OutputAdapter/OutputAdapter.csproj

```



- Adapter for input

```

 dotnet run --project Adapters/InputAdapter.csproj

```



- Input client

```

 dotnet run --project Input/Input.csproj

```



- Output client

```

 dotnet run --project Output/Output.csproj

```



### What to expect

- Logs indicate temperature changes every ~2 seconds and show pressure, mass adjustments, and safety-limit events.

- When the container is destroyed due to implosion/explosion, it resets; clients pause operations until pressure returns to a safe range.



## Configuration

- Default addresses are configured in the source files:

  - Container service host: `127.0.0.1:5000`

  - Input adapter host: `127.0.0.1:5002`

  - Controller-based adapter host: `127.0.0.1:5001`

- If you need to change ports, update them in the respective server classes.



## Concurrency and safety

- The domain logic uses an internal lock around state changes to avoid race conditions.

- Long-running background temperature updates and short request handlers are isolated via the lock to avoid deadlocks/livelocks.



## License

This project is licensed under the MIT License. See [`LICENSE`](./LICENSE).