56 lines
2.7 KiB
Markdown
56 lines
2.7 KiB
Markdown
# SignalR — Known Issues & Limitations
|
|
|
|
## Protocol
|
|
|
|
### PROTO-1: Server-side IsRawBytesData pre-serialize
|
|
|
|
**Status:** Planned removal
|
|
**Affects:** `AcWebSignalRHubBase.SendMessageToClient`
|
|
|
|
The server forwards the client's `IsRawBytesData` flag in the response `SignalParams`. This causes the protocol to return raw `byte[]` instead of deserializing. The original design pre-serialized on the server side, but with the zero-copy typed deserialization path (`SignalDataType`), this is redundant.
|
|
|
|
**Plan:** Remove `IsRawBytesData` forwarding from server response path. The client should use `SignalDataType` for typed deserialization and explicit `byte[]` type for raw data.
|
|
|
|
### PROTO-2: Parameter serialization is per-parameter
|
|
|
|
**Status:** Known performance concern
|
|
**Affects:** `SignalParams.SetParameterValues` / `GetParameterValues`
|
|
|
|
Each parameter is individually serialized via `ToBinary()` / `BinaryTo(Type)` — N context pool acquire/release cycles. For many small primitives (int, bool, string) the per-call overhead may exceed a single bulk serialization.
|
|
|
|
**Possible optimization:** Batch fast-path — single serialization context for all parameters. Benchmark first.
|
|
|
|
### PROTO-3: Parameter serialization is AcBinary only
|
|
|
|
**Status:** Limitation
|
|
**Affects:** `SignalParams.SetParameterValues` / `GetParameterValues`
|
|
|
|
Uses `ToBinary()` / `BinaryTo()` exclusively. JSON parameter support would require dispatching on `DataSerializerType` + `AcJsonSerializer` reference. Low priority — binary is the primary transport.
|
|
|
|
## Transport
|
|
|
|
### TRANS-1: BufferWriterChunkSize defaults to 64KB for SignalR
|
|
|
|
**Status:** DONE
|
|
**Affects:** `AcBinaryHubProtocol` constructor, write path
|
|
|
|
`BufferWriterChunkSize = 4096` set in `AcBinaryHubProtocol` constructor. Aligns with Kestrel slab size, reduces latency-to-first-byte. Non-SignalR paths keep 64KB default.
|
|
|
|
### TRANS-2: WebSocket buffer sizes are hardcoded
|
|
|
|
**Status:** Acceptable
|
|
**Affects:** `AcSignalRClientBase` connection setup
|
|
|
|
Transport max message size (30MB) and application buffer (30MB) are hardcoded. Sufficient for current payloads but not configurable per-deployment.
|
|
|
|
## DataSource
|
|
|
|
### DS-1: GetAll returns raw byte[] for populate/merge
|
|
|
|
**Status:** By design
|
|
**Affects:** `AcSignalRDataSource.LoadDataSourceAsync`
|
|
|
|
The `GetAll` path uses `IsRawBytesData = true` to receive raw `byte[]` from the protocol, then deserializes into the existing list via `PopulateMerge`. This avoids allocating a temporary `List<T>` for merge. The extra copy (pipe → byte[]) is the trade-off.
|
|
|
|
**Possible optimization:** Direct typed deserialization with merge support in the deserializer (PopulateMerge from `ReadOnlySequence<byte>`). Requires deserializer API changes.
|