I cannot find documentation on how to do this, and have run into issues when I've tried to implement my own based on Protobuf.
Please refer to this issue for more information: https://github.com/Azure/azure-signalr/issues/379
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Notes:
TryParseMessage should modify the ReadOnlySequence<byte> by slicing up to the amount consumed for the message parsed.TryParseMessage can give partial messages or more than 1 message at a time, so that needs to be handledAh interesting. How should partial messages be handled if it should be stateless and threadsafe? I can't seem to find special handling for this in the JsonHubProtocol.
Edit: Also, how do you handle "out"-ing multiple messages at once? Or is there some multi-HubMessage class?
For partial messages the JsonHubProtocol has a message separator and checks if that exists. If it doesn't then it returns false with no message and will be called again when there are more bytes available. https://github.com/aspnet/AspNetCore/blob/master/src/SignalR/common/Protocols.NewtonsoftJson/src/Protocol/NewtonsoftJsonHubProtocol.cs#L80
For returning multiple messages, you parse the first message, slice the input sequence and return true, then the method will be called again with the rest of the bytes
Oh, makes sense! Thanks for the explanation.
when can we expect a proper documentation about writing own protocols?
This isn't a very common scenario so it isn't a high priority doc for us to write.
The conversation above has some good information about how to write a custom protocol. You can also take a look at the current protocol implementations.
Json and MessagePack.
+1 for docs, and I'm among those who will need to protobuf due to customer and regulatory requirements.
IMHO, it's a chicken-and-egg problem. Few people are asking because since there's nothing written about it, so people assume it doesn't support Protobuf. We should prioritize it, at least with small sample. It's a common pattern in MSDN docs... see Search, TPL Dataflow and others.