- Removed SendUtils.PrepareRequst and instead used HttpClient.DefaultRequstHeaders to set the common headers to apply HttpOptions to all outbound requests
- Modified how we check for the user agent request testing
- We made a change to not initialize pipes up front
on connection creation. That change make it null ref in disposal because we didn't check if the pipes were initialized.
- Added a test
- Also fixed the EchoConnectionHandler in the functional ts tests.
- Cancel reading from the application when initiating a transport stop
- Complete each side of the pipe in the place where the pipe is being consumed
- Errors from sending end up getting sent to the application
- The Running task never throws
- Removes ContinueWith
- These are the finishing touches before we disable batching on the
C# client and on the server. We're changing the IHubProtocol interface to
modify the input buffer with what was consumed. We're also changing it
to parse a single message at a time to be match what output writing does.
- Added TryParseResponseMessage and made it look like TryParseRequestMessage
- Directly pin the char[]
- Changed Utf8BufferTextReader to use the Utf8Decoder
- It copies whatever it can into the char buffer allocated in a stateful way (it's more efficient).
- Added tests for unicode and ascii reading
- Added a thread static cache
* Progress towards deleting Sockets.Abstractions
- Moved our custom DefaultConnectionContext to Sockets.Http and renamed it to HttpConnectionContext.
- Renamed ConnectionManager to HttpConnectionManager
- Use DefaultConnection in tests and benchmarks
- Delete ConnectionMetadata
- React to rename of EndPoint to ConnectionHandler
- Rename UseSockets to UseConnections
- Rename MapEndPoint to MapConnectionHandler
- Rename HttpSocketOptions to HttpConnectionOptions
- The long polling transport simulates a persistent connection
over multiple http requests. In order to expose common http request
properties, we need to copy them to a fake http context on the first poll
and set that as the HttpContext exposed via the IHttpContextFeature.
- Made HubCallerContext an abstract class
- Made DefaultHubCallerContext that gets data from the HubConnectionContext.
- Removed IP address
- Removed Connection property
- Don't allocate when enumerating connections
- Don't allocate tasks unless we truly go async
- Don't get the timestamp, just write the pings always (if there's no ongoing write)
- Track the time since last keep alive write instead of the last write
- ValueTask all the things!
- Renamed HubConnectionList to HubConnectionStore
- Introduced Utf8BufferTextReader that writes buffers directly into
the char[] allocated by JSON.NET when reading via the JsonReader.
- Use IArrayPool implementation over ArrayPool<char> when reading
incomming messages.
- Replaced JToken parsing with manual parsing using JsonTextReader.
- Added tests for parsing incoming JSON messages with out of order
properties.
- Make access to message headers lazy
- Changed IHubProtocol.TryParseMessage to be ReadOnlyMemory<byte> instead of ReadOnlySpan<byte>
- This PR attempts to move things where they are needed instead of where they
happened to be used. As a result we should now have Sockets.Abstractions and
Sockets down to the minimal set of things required to make them run.
Sockets.Abstractions should go away in favor of Protocol.Abstractions and
Sockets contains the EndPoint abstraction and related types.
- Moved ConnectionManager and friends to
Sockets.Http.
-Removed Sockets and moved everything into Sockets.Abstractions.
- Moved DefaultConnection and put it in Sockets.Abstractions.
* 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
Before we would rely on error being null to detect whether to read results and we had an additional 'hasResult' field. Now all this information is codified in a field.
* Features everywhere
- The goal here is to move things closer to the final design where
ConnectionContext represents a very low level primitive that represents
any connection like transport. As part of that change, we remove unnecessary
properties like User and move those into features. They temporarily live in the same
assembly but they are not required by ConnectionContext.
- Used features for Hubs instead of Metadata
- Metadata is no longer thread safe
* Replace ConnectionContext with HubConnectionContext
- The SocketDelegate implementation owns the transport pipe,
it's a single producer single consumer model. SignalR needs to support
multiple producers so that broadcast, return values and sending to individual
connections works. This change introduces a multi producer channel that is used
by all producers to copy data to the transport safely. This will make the move
to pipelines easier.
- Remove timeout and closed the application when the transport closes.
Made some tweaks to TestWebSocketConnectionFeature as a result.
- This uncovered some interesting issues with the WebSocketTransport itself so
further refactoring is needed to make it a bit more solid.
Pavel Krymets
James Newton-King
BrennanConroy
David Fowler
Andrew Stanton-Nurse
Mikael Mengistu
Ryan Brandenburg
Josh Williams
Geovanny Alzate Sandoval
Pawel Kadluczka
Pawel Kadluczka
Pawel Kadluczka
Pranav K
Nate McMaster
ivankarpey
FTWinston
LivioF
Nate McMaster
Hao Kung