geutebruck/geutebruck-api/SDK_ARCHITECTURE_ISSUE.md

# SDK Architecture Issue - Root Cause Analysis

**Date**: 2025-12-10
**Status**: 🔴 **BLOCKING ISSUE IDENTIFIED**

---

## Problem Summary

The SDK Bridge cannot connect to servers, returning `connectRemoteUnknownUser` error. After extensive testing, **this is NOT a credential problem** - it's an **SDK architecture problem**.

## Root Cause Discovered

### The SDK Bridge is using the WRONG SDK!

**Current Implementation (INCORRECT)**:
```csharp
using GEUTEBRUECK.GeViSoftSDKNET.ActionsWrapper;  // GeViSoft SDK
using GEUTEBRUECK.GeViSoftSDKNET.ActionsWrapper.ActionDispatcher;
```

The SDK Bridge is trying to use the **GeViSoft SDK** to connect to **BOTH servers**:
1. GSCServer (GeViScope) - ❌ **WRONG SDK**
2. GeViServer (GeViSoft) - ✅ Correct SDK

###There are TWO Separate SDKs

**GeViScope SDK** (for GSCServer - video operations):
- `GscActionsNET_4_0.dll`
- `GscDBINET_4_0.dll`
- `GscExceptionsNET_4_0.dll`
- `GscMediaPlayerNET_4_0.dll`

**GeViSoft SDK** (for GeViServer - configuration/management):
- `GeViProcAPINET_4_0.dll` (what we're currently using)
- `G-ActionsNET_4.0.dll`
- `GngActionsNET_SDK.dll`
- `GngDBINET_SDK.dll`

## Evidence

### 1. Successful Connection Log
`C:\GEVISOFT\GeViSoftConfigReader.log` shows:
```
2025-12-08 15:46:42: Server: localhost, User: sysadmin
2025-12-08 15:46:42: Connect() returned: connectOk
2025-12-08 15:46:42: Connected successfully!
```

**This connected to GeViServer (GeViSoft), NOT GSCServer (GeViScope)!**

### 2. SDK Documentation
From `GeViSoft_SDK_Documentation.md`:
```
the user name to sysadmin. Check Save password and set the password to masterkey.
```

Credentials are correct: `sysadmin` / `masterkey`

### 3. Automated Credential Testing
Tested 48 username/password combinations:
- 6 usernames: sysadmin, admin, administrator, root, geviscope, gevisoft
- 8 passwords: "", masterkey, admin, password, geviscope, gevisoft, 123456, geutebruck

**NONE worked for GSCServer** - because we're using the wrong SDK.

## File System Evidence

**C:\GEVISOFT** contains separate DLL sets:
```
Gsc*.dll     → GeViScope SDK (for GSCServer)
Gng*.dll     → GeViSoft Next-Gen SDK
GeViProc*.dll → GeViSoft Process API (what we're using)
```

**C:\Program Files (x86)\GeViScopeSDK** exists separately from GeViSoft installation.

## The Architecture Should Be

```
SDK Bridge
├── GeViScope Connection (GSCServer - video ops)
│   └── Uses: GscDBINET_4_0.dll
│       └── Class: GeViScopeDatabase (or similar)
│
└── GeViSoft Connection (GeViServer - config)
    └── Uses: GeViProcAPINET_4_0.dll (current)
        └── Class: GeViDatabase ✅ (already implemented)
```

## Current vs. Correct Implementation

### Current (Broken)
```csharp
// Program.cs lines 45-50
var geviScopeWrapper = new GeViDatabaseWrapper(  // ❌ Using GeViSoft SDK
    geviScopeHost,
    geviScopeUsername,
    geviScopePassword,
    Log.Logger);
```

### What It Should Be
```csharp
// Need TWO different wrapper classes:

// For GeViScope (GSCServer)
var geviScopeWrapper = new GscDatabaseWrapper(  // New class needed
    geviScopeHost,
    geviScopeUsername,
    geviScopePassword,
    Log.Logger);

// For GeViSoft (GeViServer)
var geviSoftWrapper = new GeViDatabaseWrapper(  // Current class - OK
    geviSoftHost,
    geviSoftUsername,
    geviSoftPassword,
    Log.Logger);
```

## What Needs to Be Fixed

### 1. Add GeViScope SDK References
**GeViScopeBridge.csproj** needs:
```xml
<ItemGroup>
  <!-- Existing GeViSoft SDK -->
  <Reference Include="GeViProcAPINET_4_0">
    <HintPath>C:\GEVISOFT\GeViProcAPINET_4_0.dll</HintPath>
  </Reference>

  <!-- NEW: Add GeViScope SDK -->
  <Reference Include="GscDBINET_4_0">
    <HintPath>C:\GEVISOFT\GscDBINET_4_0.dll</HintPath>
  </Reference>
  <Reference Include="GscActionsNET_4_0">
    <HintPath>C:\GEVISOFT\GscActionsNET_4_0.dll</HintPath>
  </Reference>
  <Reference Include="GscExceptionsNET_4_0">
    <HintPath>C:\GEVISOFT\GscExceptionsNET_4_0.dll</HintPath>
  </Reference>
</ItemGroup>
```

### 2. Create GscDatabaseWrapper.cs
New file: `SDK/GscDatabaseWrapper.cs`
- Similar to `GeViDatabaseWrapper.cs`
- Uses GeViScope SDK classes instead
- Connects to GSCServer for video operations

### 3. Update Program.cs
Use correct SDK wrapper for each server:
- **GSCServer** → `GscDatabaseWrapper`
- **GeViServer** → `GeViDatabaseWrapper` (unchanged)

### 4. Update Service Implementations
Services using GeViScope (video ops) should use `GscDatabaseWrapper`:
- `CrossSwitchService.cs`
- `MonitorService.cs`
- `CameraService.cs`

Services using GeViSoft (config) stay unchanged:
- `ActionMappingService.cs` ✅

## Testing After Fix

Once fixed, test connection with known-good credentials:
```json
{
  "GeViScope": {
    "Host": "localhost",
    "Username": "sysadmin",
    "Password": "masterkey"
  },
  "GeViSoft": {
    "Host": "localhost",
    "Username": "sysadmin",
    "Password": "masterkey"
  }
}
```

**Expected Result**:
```
[INF] Connecting to GeViScope (GSCServer)...
[INF] Successfully connected to GeViScope    ← Should work now
[INF] Connecting to GeViSoft (GeViServer)...
[INF] Successfully connected to GeViSoft     ← Already works
[INF] gRPC server starting on port 50051
```

## Why This Wasn't Obvious

1. **Both SDKs use similar patterns** - Create(), Connect(), Dispose()
2. **Naming confusion** - "GeViDatabase" is from GeViSoft SDK, but sounds generic
3. **Error message misleading** - "connectRemoteUnknownUser" suggests auth problem, not SDK mismatch
4. **Documentation gap** - Wasn't clear that two separate SDKs exist

## Next Steps

1. **Research GeViScope SDK documentation** in `C:\Program Files (x86)\GeViScopeSDK\Documentation`
2. **Examine example code** in `C:\Program Files (x86)\GeViScopeSDK\Examples`
3. **Implement GscDatabaseWrapper** using GeViScope SDK
4. **Update all services** to use correct SDK
5. **Test connection** - should succeed immediately with sysadmin/masterkey

---

## Summary

- ✅ **Credentials are correct**: `sysadmin` / `masterkey`
- ❌ **SDK is wrong**: Using GeViSoft SDK for GeViScope server
- 🔧 **Fix required**: Add GeViScope SDK support via GscDBINET_4_0.dll
- ⏱️ **Estimated fix time**: 2-3 hours of implementation

**Once the correct SDK is used, connection should work immediately with the credentials we already have.**