Closed iniside closed 6 years ago
The spec docs are pretty thorough and give examples of the json payloads you send for each message type (including the type id for that message)
https://github.com/aspnet/SignalR/blob/release/2.2/specs/HubProtocol.md#invocation-message-encoding
type - A Number with the literal value 1, indicating that this message is an Invocation.
Example:
{
"type": 1,
"invocationId": "123",
"target": "Send",
"arguments": [
42,
"Test Message"
]
}
Is there something missing that could help make this clearer?
Hey thanks for answer.
{
"type": 1,
"invocationId": "123",
"target": "Send",
"arguments": [
42,
"Test Message"
]
}
In that particular example I'm not sure what "type:" 1 means. I think it is Invocation Message but there are also other message types (like Invocation streaming). It would be nice to know which number corresponds to which message type and have short example for every message type.
Each of the message types are listed in the spec document @BrennanConroy linked to along with the type
value. Did you read the document? There's a whole section on the JSON encoding and it includes a complete list of message types. Each of those sections also specifies the exact value for the type
field.
Hey thanks
I got it working, in the end it was all about missing termination byte.
Hey
I will first say what I want to do. I'd like to use SignalR for providing API for some backend services. I also want to create integration for Unreal Engine. I know there is some CPP client code, but it has quite a bit dependencies which are covered by Unreal own std library. There is: https://github.com/aspnet/SignalR/blob/release/2.2/specs/HubProtocol.md
But it does not really describe exact specification of message. There are some descriptions but for example it lack which value corresponds to which type (since it is provided in integer and types are described in docs as strings).
Would it be possible to add samples of raw messages that can be send as JSON trough raw WebSocket connection and which are then properly handled by underlaying SignalR server. That would make far easier creating custom SingalR clients for platforms which are not supported officially.