* Do over the websocket transport
- Unify client and server logic (no code sharing yet)
- Removed use of cancellation tokens to communicate shutdown and instead used the pipe reader and socket abort.
- Added CloseTimeout to HttpOptions
* Tackling some low hanging performance fruit
- Use native Memory/Span APIs on Stream and WebSocket in .NET Core 2.1
- Remove double copying in formatters
- Implemented custom HttpContent over ReadOnlyBuffer<byte>
* Remove timeout from receive tcs.
- This test echos a large message and it fails sometimes before the entire thing is delivered. Just drop the timeout.
- Avoid creating timers for already completed tasks
* Remove the Channel<HubMessage> from the HubConnectionContext
- Replace the channel with a single lock around the pipewriter. Since writes are always synchronous, the lock is held for a very short time.
- We were only using them in this scenario for handling multiple producers (the hub output, the keep alive ping and the broadcast).
- Handle the scenario where there's back pressure (when we use pipes that are bounded) and give callers a single task representing when back pressure is released.
- Handle synchronous exceptions in RedisHubLifetimeManager
- Fixed benchmarks
- Reworked the Client to be based on pipelines instead of Channels
- SendAsync no longer fails if the http request itself fails but the connection is closed as a result.
- Updated tests
- Base64Encoder needed to support multiple messages in the same span of data
* Throw InvalidDataException instead of FormatException in NegotationProtocol
- Modify NegotiationProtocol to throw InvalidDataException
- Update NegotiationProtocolTests expectations
- Remove test case for InlineData "Missing required property 'protocol'"
- Update JsonHubProtocol & JsonUtils to throw InvalidDataException
- Update corresponding test expectations
- Add back removed test
Addresses #1203
SendAsync was using InvokeCoreAsync code to send messages. In case of exception InvokeCoreAsync is blocking and returns a task to the user so they can await for the remote call to complete. Any exception thrown is caught and used to fail the task returned to the user. SendAsync does not return a special task to the user so re-using InvokeCore resulted in swallowing exceptions. While SendAsync is fire and forget it actually should throw if the message could not be send and it was not happening.
While adding tests it turned out we did not test cases where Invoke/SendAsync/StreamAsync were invoked before starting the connection and this resulted in a NullReferenceException. I also fixed that.
When the client cancels a streaming method the server would send an error completion. This was not correct because cancellation is not an error. We did not see this because our client ignores any messages for a given streaming invocation after sending a CancelInvokationMessage but other clients may want to drain messages before considering a streaming method canceled.
Late parameter binding
Storing exception thrown during parameter binding and rethrowing when the method is about to throw. This allows completing invocations with a HubException and keeping the connection open.
We will also no longer close the connection if parameters for client side methods cannot be bound. We will log and continue.
Fixes: #818
(Also fixing #1005 because I was just touching this line)
* fix issue with incorrect user detection when Invoking for User
* fix failed testcases
* use proper extension method to avoid potential null reference exception
* fix for channel name in redis version + follow SignalR team recommendations
* remove unncessary freespace
* remove whitespaces
* introduce IUserIdProvider to resolve user id
* Move IUserIdProvider from HubLifetimeManager to HubConnectionContext
* setting user id to connection context in hubendpoint
* Remove the params argument from IClientProxy
- This allows passing arrays without having to explicitly ToArray() or AsEnumerable()
- Added overloads up to 10 arguments
- Added tests
* Initial support for websocket subprotocols
- Exposes a SubProtocol property on WebSocketOptions that picks the
protocol for all connections on the end point.
- This is required for things like mqtt over websockets (the SubProtocol in
this case is something like mqtt or mqttv3.1)
- Added test
#402
We need to close the connection if there is an exception when writing to the transport on the server side. Currently if an exception happens it leaves the connection in an unsable state - after the exception no messages from the server will be sent to the client because the writing loop is terminated. Ignoring the message could cause hangs on the client side since we can fail while writing a completion message. In this case if the client is awaiting the invocation it will hang because the task will never be completed.
* Turned Stream into StreamAsync
- Before we were fire and forgetting the invocation that initiated
the streaming, this changes that so that the caller now has to await
to get the channel.
#899
* Added Cancellation support
- Added ConnectionAbortedToken to the HubConnectionContext. This allows
arbitrary code to access a handle that represents the connection lifetime
without handling OnDisconnectedAsync on the hub itself.
- Expose Abort on HubConnectionContext to allow server side methods to
abort the connection.
- Use the Abort to stop the main loop when unexpected invocation errors happen.
- Use the connection aborted token as unsubscribe from the IObservable and to complete
the IAsyncEnumerator for streaming results.
- Removed ConnectionFactoryDelegate and used Func<IConnection>
- Changed WithLogger that accepts ILoggerFactory to WithLoggerFactory
- Made UseLogger configure the existing ILoggerFactory or create a LoggerFactory
- Add support for setting the log level for console logs
- Updated tests
Mikael Mengistu
James Newton-King
Andrew Stanton-Nurse
Pavel Krymets
BrennanConroy
Ryan Brandenburg
David Fowler
Josh Williams
Geovanny Alzate Sandoval
Pawel Kadluczka
Pawel Kadluczka
Pawel Kadluczka
Pranav K
Nate McMaster
ivankarpey
FTWinston
LivioF