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
BrennanConroy
Mikael Mengistu
John Luo
Pawel Kadluczka
Hao Kung
David Fowler
Andrew Stanton-Nurse
Pavel Krymets
Pawel Kadluczka
Andrew Stanton-Nurse
Chris R
Kai Ruhnau
Alexis Nowikowski
Pawel Kadluczka
Nate McMaster
Pranav K