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.
* Added support for non blocking sends on HubConnection
- Renamed Invoke to InvokeAsync
- Add support for non blocking send to TS client
- Add tests to make sure that non blocking sends don't send responses
* Re-layer the .NET Client into Http and non-Http
- Moved IConnection to Sockets.Abstractions and removed
HttpConnection and TransportType dependency.
- Renamed Sockets.Client to Sockets.Client.Http
- Renamed Sockets.Common to Sockets.Common.Http
- Renamed Connection to HttpConnection
- Removed HTTP dependency from HubConnection
- Removed tests that were testing connection logic in HubConnection
#518
* Add support for timing out poll requests
- Default poll request is 110 seconds (like in previous versions of SignalR)
- Use 200 with a 0 content length for timeouts.
- Added support for not timing out while debugging
* Merge transport and hub protocols
- This change merges the transport and hub protocols into a single protocol. The
idea being that sockets in a purely streaming layer that sends frames from the underlying
transport. This makes things like TCP possible and doesn't impose a framing layer at the lowest
level. This will make it possible to build servers like kestrel on top of the TCP layer.
- The Message was removed from the lowest layer of the stack and pushed into the hubs layer. Hub invocations
are framed with what was before the transport protocol. Connections also need to state upfront if they support
binary or not. This will determine how data will be serialized to the specific connection.
- Changed the SSE parser and writer to be strictly SSE without any of the transport protocol specific
information.
- To ensure we aren't using types in the wrong layers
- Moved protocol logic into SignalR
- Socket.Abstractions is now the root of the universe, Sockets.Common will likely be removed
or turned into Sockets.Common.Http.
- Move SSE parser to Sockets.Client and SSE writer into Sockets.Http
- Moved tests into the appropriate test projects
- Updated the spec
* Remove the RequestId from DefaultConnectionContext
- Added a GetHttpContext() extension method on ConnectionContext
- Also fixed an issue not setting LastSeenUtc
- Preventing from closing long polling transport with 204 in case of
error
- Reporting an error to the client if WebSocket was not closed normally
Note in case of ServerSentEvents it is not possible on the client to
tell the difference between when the server closed event stream due to
an exception or because the client left OnConnectedAsync. In both cases
the client sees only that the stream was closed.
Part of: #163
Exceptions thrown when sending or receiving messages would leave the
WebSockets transport in a half-closed state when one of the loops is
closed but the other one is still running preventing from the
Connection.Closed event to be fired.
Fixes: #412
* Split http and non-http layers
- This change introduces Microsoft.AspNetCore.SignalR.Http
and Microsoft.AspNetCore.Sockets.Http which expose extension methods
on IAppBuilder for wiring up a sockets and signalr pipeline.
* Progress towards splitting the layers
- This is based on the work anurse did in anurse/endpoint-middleware-spike to
introduce a connection middleware pipeline that mimics much of our http
pipeline. The intent is that this layer will be generic enough to build both
SignalR and Kestrel on top of but we're not there yet. This change makes incremental
progress towards splitting apart sockets and http so that we can add the tcp transport
without breaking everything all at once.
- Created Microsoft.AspNetCore.Sockets.Abstractions where the primitives for
sockets live. That includes, ConnectionContext (formerly Connection), EndPoint,
ISocketBuilder, SocketDelegate, etc.
- ConnectionContext isn't in it's final form as yet, it still very closely mirrors
the original Connection object we had so that tests continue to pass.
- The HttpConnectionDispatcher doesn't know about EndPoint anymore, it just cares
about invoking the SocketDelegate.
- EndPointOptions has been removed as part of this change as it coupled http specific configuration
to the end point type. There's a new HttpSocketOptions that needs to be passed into MapSocket calls.
- Updated the tests to deal with the API changes.
- If a message was sent and the application was ended in the same
poll request, the connection would be closed by the time the next poll
came in which resulted in a 404. This change waits until the transport writes
all data before closing it.
- Also fixed a test so that the exception started to show client side.
#469
- We're now using the routing system in a very vanilla way now that
we're not using the URL space as part of the protocol.
- Removed the path argument from the HttpConnectionDispatcher (simplifies code and removes duplication from tests)
* convert to new protocol
* removed InvocationDescriptorRegistry because we're not yet sure about custom protocols
* update SocialWeather sample
* Moving ts client to using new protocol
* make the functional tests a little easier to run on ctrl-f5
Firefox won't fire EventSource open event until it receives some data. The workaround is to send an empty comment when starting ServerSentEvent transport.
Fixes: #352
* Disable response buffering via the IHttpBufferingFeature
- To make sure SignalR works with servers and middleware
that do perform response buffering, disable it via the
IHttpBufferingFeature for SSE.
- Added test to verify buffering is disabled
- Today we don't end the request if the application completes
but the websocket transport hasn't gotten the receive frame as yet.
This changes adds a WebSocketOptions.CloseTimeout to EndPointOptions
that allows configuring this timeout. When the timeout is reached, we abort
the connection and end the transport task so that the request can end.
- Added tests for websocket timeout and skipped tests for application timeouts
* Fix issue where multiple calls to dispose don't wait properly
- DisposeAsync returned immediately to anyone but the first caller.
This means that it was possible to end the request before properly
waiting on the transport task which means writing after dispose was possible.
- Added a test
We had a startTask we would await in DisposeAsync and channel completion continuation. This task would be initially set to a completed task and then once StartAsync was invoked it would be replaced with the actual task representing StartAsyncInternal. However if a transport failed immediately after starting the channel completion continuation could have been called before the StartAsyncInternal method completed. In this case we would await the inital completed task and then very likely would fail trying to await _receiveLoop task because it wouldn't necessarily be set.
The fix is to use TaskCompletionSource so we don't try to swap tasks. We need to do some additional state checks because:
- the TaskCompletionSource task may never be completed (e.g. DisposeAsync is being called without starting the connection)
- TaskCompletionSource allows setting the result only once and we should not return its task more than once (e.g. calling StartAsync after connection was successfully started and stopped)
Fixes#304
Fixing a race where removing the last message from the channel would trigger draining the event queue (in channel Completion continuation) which would prevent from raising the Received event for the very message that was read from the channel.
- Creating an MSBuild project for the TS client
- Adding project references to the TS client project from projects that need the client - (ensures the correct targets dependency graph and prevents building the client multiple times and related races)
- Removing gulp tasks from individual projects (allows containing npm only in the TS client source and node tests)
- Using incremental compilation to build the TS client only when inputs change (prevents building the client multiple times or when not needed at all)
- Removing `npm install` from all the projects (takes up to 10 seconds even if there is nothing to restore) - npm packages will still be installed when running full build (if needed) or need to be installed manually
* Fixed parameter count mismatch when invoking methods with wrong case
- Hub methods were being tracked with 2 dictionaries, one for parameter names
the other for callbacks. This change introduces a single dictionary that stores
the hub name to a HubMethodDescriptor. That descriptor stores the parameter types
and method info for the bound hub method.
- The callback is now just an invoke method on the HubEndPoint itself.
- Added tests for case sensitivity in hub method names
- It was possible for the application to be torn down during
a background scan. When that happened, the timer would be disposed
before the end of the scan and would throw an ObjectDisposedException
when timer resumption happened. This change introduces a lock that avoids that
race.
Fixes#161
* Handle misbehaving user code
- Execute EndPoint logic on a threadpool thread
- Turn synchronous exceptions into async ones to unify the
error handling
- Added tests
- The connection state object is manipulated by multiple parties in a non thread safe way. This change introduces a semaphore that should be used by anyone updating or reading the connection state.
- Handle cases where there's an active request for a connection id and another incoming request for the same connection id, sse and websockets 409 and long polling kicks out the previous connection (https://github.com/aspnet/SignalR/issues/27 and https://github.com/aspnet/SignalR/issues/4)
- Handle requests being processed for disposed connections. There was a race where the background thread could remove and clean up the connection while it was about to be processed.
- Synchronize between the background scanning thread and the request threads when updating the connection state.
- Added `DisposeAndRemoveAsync` to the connection manager that handles`DisposeAsync` throwing and properly removes connections from connection tracking.
- Added Start to ConnectionManager so that testing is easier (background timer doesn't kick in unless start is called).
- Added RequestId to connection state for easier debugging and correlation (can easily see which request is currently processing the logical connection).
- Added tests
* Clean up disposal of connection state
- Removed IDisposable and added a DisposeAsync method to ConnectionState
- Added ApplicationTask and TransportTask to ConnectionState as first class
properties so that it is easy to see (in a process dump or debugger) the
outstanding tasks that Sockets is keeping track of on a per connection basis.
* Allow processing of other incoming invocations in parallel
- Don't wait on the response of an invocation to pick up
the next message from the channel.
- Unhandled exceptions should continue bubbling up correctly
* rename getid to negotiate
* also change SSE and Long Polling to require a pre-established connection
* disallow changing transports mid-connection; return a 400 response if the user attempts to do so
* Use TryRead and TryWrite
- Use TryWrite to avoid errors on channel close for /send requests
- Use TryRead until it returns false for all transports but long polling
- Remove Streaming* classes from Sockets. The main
API will be channels based and streaming transports
will use the PipelineChannel (formerly FramingChannel) to
access messages.
- Added WriteAsync and ReadAsync to Connection and hid
the IChannelConnection from public API.
- Also fixed the fact that unknown methods caused server side
exceptions.
- Changed the consumption pattern to WaitToReadAsync/TryRead to avoid
exceptions.
- React to API changes
- Fixed ChannelConnection to use IChannel<T> for
both sides of the connection. This allows use to close both the
input and the output when we are tearing down.
- Use TryComplete instead of complete to avoid exceptions thrown on
Complete(), particularly ChannelClosedException.
* Need a separate set of primitives to handle messaging
* Using Channels (not Pipelines!) to provide the data flow for messaging
* All transports are now "message" based transports
* Added an adaptor to convert message-based transports to serve
streaming endpoints
Making sure that OnConnected/OnDisconnected events are invoked correctly (e.g. if invoking OnDisconnectedAsync on hub threw we would not call OnDisconnectedAsync on lifetime manager and therefore we would continue to use/track connections that were already closed)
* Clean up shutdown management
- ConnectionManager now implements IApplicationEvents. It makes testing cleaner
but makes service registration a little messy.
* Cleaned up service registration and layering a bit
- Added SocketsApplicationLifetimeEvents instead of implementing it
on ConnectionManager directly.
- Exposed ConnectionManager.CloseConnections()
* add tests to WebSockets transport
* adds some error handling
* make logger factory required
* allow frames to be received after the application closes the output