Per this SO for a net client (with either binary or string data encoding) the 1st message is received and treated properly and usually the 2nd but from then on messages are truncated. This causes a crash at RSocketProtocol.Handler.cs where the header type is unknown and therefore not handled.
To replicate the error start a Java spring boot RSocket server. Then spin up a net client with code like this:
If you watch the message sizes coming in, the 1st message size is what you expect from your server (fielding dummy messages) but the next message sizes are unexpected.
Per this SO for a net client (with either binary or string data encoding) the 1st message is received and treated properly and usually the 2nd but from then on messages are truncated. This causes a crash at RSocketProtocol.Handler.cs where the header type is unknown and therefore not handled.
To replicate the error start a Java spring boot RSocket server. Then spin up a net client with code like this:
The server uses
webflux
to stream back to the client. Get the RSocket.Core and put a breakpoint at https://github.com/rsocket/rsocket-net/blob/master/RSocket.Core/RSocketProtocol.Handler.cs#L30If you watch the message sizes coming in, the 1st message size is what you expect from your server (fielding dummy messages) but the next message sizes are unexpected.