Non-serialized hub invocations

[Tragetaschen]

I have tried to circumvent the missing stream invocations in the Java client by introducing for each streaming method on my Hub a sibling method that would await and return the next value that a ChannelReader would provide. The client would then have to immediately invoke the same method again after receiving a value to simulate continuous values. In my C# design validation client, I try to invoke two methods, run Task.WhenAny and then re-issue the finished invocation.

However, the invocation serialization from 1957655 means that any additional incoming message on the connection will only be dispatched when a running (async-blocking) invocation has finished. This includes any second invocation, a new streaming invocation and (which is where it's likely getting interesting) any form of graceful connection abort from the client. As far as I could see in the code for the latter case, all forms of Abort (which would trigger the cancellation token) originate from outside the dispatch loop, so only actually reading from the input pipe can close a connection which is blocked by the running invocation.

So: Personally, I'd love to see lifting the restriction around non-streaming invocations...

[analogrelay]

We can revisit this in 3.0. We intentionally disabled concurrent invocations because there was some concern around memory issues. We lifted the restriction for streaming invocations because they don't make sense with that restriction. We can revisit this though in 3.0

[BrennanConroy]

For design: Here is a short conversation about making the invocations serial aspnet/SignalR#2086 (comment)