Fix #324 by adding streaming support to the server #461

analogrelay · 2017-05-18T19:36:01Z

There are a few small WIP items:

TypeScript Client support. I'm not totally happy with it. Contemplating just removing it from this PR, since it doesn't affect the server and the server has tests for it's behavior
Going to change StreamingAttribute to target the method, not the return value. The return value may be the technically correct place to annotate this but the method is the intuitive place
Haven't written the C# client support. Again, I'm not sure we should do that in this PR.

We only support ReadableChannel<T> and IObservable<T> right now. Stream is a little trickier so I haven't done it yet.

davidfowl · 2017-05-19T04:37:20Z

samples/SocketsSample/Hubs/Streaming.cs

+{
+ public class Streaming : Hub
+ {
+ [return: Streaming]


Remind me why we need the attribute [Streaming]? Either way I think we can just get rid of it and just always stream IO<T> and ReadableChannel<T>.

I originally had that thought but when we talked last we decided to use an attribute to make it clear. It's a little less clear around something like IAsyncEnumerable<T>. Do you want to load up all the data before returning a result or stream it out?

But if you think it's clear that IAsyncEnumerable<T> should be streamed, we can get rid of the attribute.

davidfowl · 2017-05-19T04:38:31Z

src/Microsoft.AspNetCore.SignalR/HubEndPoint.cs

@@ -295,6 +307,68 @@ public class HubEndPoint<THub, TClient> : EndPoint, IInvocationBinder where THub
 }
 }

+ private bool IsChannel(Type type, out Type payloadType)
+ {
+ var channelType = type.AllBaseTypes().FirstOrDefault(t => t.IsGenericType && t.GetGenericTypeDefinition() == typeof(ReadableChannel<>));


This doesn't look very efficient 😄

It'll go away when we have IAsyncEnumerable<T>, because we can just cast and call GetEnumerator

When we get C# 8? 😄 We'll need to make this better in the mean time, file an issue.

To be fair, the type doesn't have to wait for C# 8, and wouldn't require a new netstandard version.

davidfowl · 2017-05-19T04:39:19Z

src/Microsoft.AspNetCore.SignalR/HubEndPoint.cs

+ else
+ {
+ // This type cannot be streamed
+ throw new NotSupportedException($"Cannot stream results of type: {result.GetType().FullName}");


Observable of 1 item?

If we keep the attribute, sure. But if we remove the attribute then single results just won't be streamed.

Yes let's nuke it

davidfowl · 2017-05-19T04:40:24Z

src/Microsoft.AspNetCore.SignalR/Internal/AsyncEnumeratorAdapters.cs

+ while (!_output.TryWrite(value))
+ {
+ // Wait for a spot
+ if (!_output.WaitToWriteAsync(_cancellationToken).Result)


Task queue would be better...

But we still have to block this thread to create backpressure. Otherwise the caller will just keep invoking OnNext and the tasks will queue up. That's why IObservable is less ideal. If we're OK overrunning the Task Queue, then we can just queue things up.

Yes but the you can block after some threshold.

Isn't that threshold just defined by the channel we create? Right now it's unbounded, but we can create a bounded channel. Also, how does the blocking work with the Task queue? Do we need to track how many outstanding tasks we have in the Adapter and then block when it hits a certain threshold?

Using the channel for this seems simpler.

I see, that makes sense.

davidfowl · 2017-05-19T04:46:04Z

Haven't written the C# client support. Again, I'm not sure we should do that in this PR.

We need either the C# client or the typescript client to be part of this PR. Otherwise I'm not sure we have anything real.

davidfowl · 2017-05-19T05:36:05Z

Running the ChannelCounter fails in the sample. You need more tests:

{System.InvalidCastException: Unable to cast object of type 'AsyncEnumerator[System.Int32]' to type 'System.Threading.Tasks.Channels.IAsyncEnumerator`1[System.Object]'.
   at Microsoft.AspNetCore.SignalR.Internal.AsyncEnumeratorAdapters.FromChannel(Object readableChannelOfT, Type payloadType) in C:\dev\git\SignalR\src\Microsoft.AspNetCore.SignalR\Internal\AsyncEnumeratorAdapters.cs:line 38
   at Microsoft.AspNetCore.SignalR.HubEndPoint`2.IsStreamed(ObjectMethodExecutor methodExecutor, Object result, IAsyncEnumerator`1& enumerator) in C:\dev\git\SignalR\src\Microsoft.AspNetCore.SignalR\HubEndPoint.cs:line 362
   at Microsoft.AspNetCore.SignalR.HubEndPoint`2.<Invoke>d__15.MoveNext() in C:\dev\git\SignalR\src\Microsoft.AspNetCore.SignalR\HubEndPoint.cs:line 284}

I did this hackery to make it work:

public static IAsyncEnumerator<object> FromChannel(object channel, Type itemType)
{
    return (IAsyncEnumerator<object>)_fromChannelMethod
        .MakeGenericMethod(itemType)
        .Invoke(null, new[] { channel });
}

public static IAsyncEnumerator<object> FromChannel<T>(ReadableChannel<T> readableChannel)
{
    return FromObservable(readableChannel.AsObservable());
}

The co-variance doesn't work for value types so IAsyncEnumerator<int> can't be assigned to IAsyncEnumerator<object>.

analogrelay · 2017-05-19T16:39:26Z

We need either the C# client or the typescript client to be part of this PR. Otherwise I'm not sure we have anything real.

We need to review the client API before we can go very far there. Does the client have to call a different method? StreamAsync instead of InvokeAsync? Or do we try to infer based on return type? If the latter, things get kinda hairy with the inference and adapting on both ends, but we can try to make it work.

analogrelay · 2017-05-19T16:41:51Z

The co-variance doesn't work for value types so IAsyncEnumerator can't be assigned to IAsyncEnumerator.

Yep, that's co-variance. Indeed. Absolutely. Correct.

analogrelay · 2017-05-19T16:54:21Z

I'm going to drop the TS client and spike out a C# client API to unblock the PR. The TS client requires building a whole primitive for streaming, whereas the C# one does not.

davidfowl · 2017-05-19T17:03:08Z

Isn't "out" - co-variant and "in" contravariant?

analogrelay · 2017-05-19T17:11:50Z

That's totally what I said. Check again.

BrennanConroy · 2017-05-19T17:59:58Z

samples/SocketsSample/SocketsSample.csproj

@@ -9,6 +9,9 @@
 </PropertyGroup>

 <ItemGroup>
+ </ItemGroup>


BrennanConroy · 2017-05-19T18:01:21Z

samples/SocketsSample/wwwroot/index.html

@@ -18,5 +18,11 @@
 <li><a href="hubs.html?transport=ServerSentEvents">Server Sent Events</a></li>
 <li><a href="hubs.html?transport=WebSockets">Web Sockets</a></li>
 </ul>
+ <h1>ASP.NET SignalR (Streaming)</h1>


Could you add Core to all these

BrennanConroy · 2017-05-19T18:32:50Z

src/Microsoft.AspNetCore.SignalR/Internal/AsyncEnumeratorAdapters.cs

@@ -0,0 +1,87 @@
+using System;


analogrelay · 2017-05-19T18:51:11Z

Small incomplete update to fix simple comments (Channel streaming co-variance, some JavaScript bugs).

I think I'm going to add automated tests for the TypeScript client and then look in to C#.

Still to come:

Remove Streaming attribute
Add TypeScript client tests
Add C# client code
Add C# client tests.

moozzyk · 2017-05-19T17:46:47Z

src/Microsoft.AspNetCore.SignalR/HubEndPoint.cs

@@ -276,17 +281,24 @@ public class HubEndPoint<THub, TClient> : EndPoint, IInvocationBinder where THub
 result = methodExecutor.Execute(hub, invocationMessage.Arguments);
 }

- return CompletionMessage.WithResult(invocationMessage.InvocationId, result);
+ if (hasResult && IsStreamed(methodExecutor, result, out var channel))


I think hasResult will be true here for void methods. Not sure if this is harmful but it will be surprising if someone needs to investigate.

Also, I don't know what the value of result here is but if it is null than we will possibly fail in a weird way (like NRE) if someone puts the attribute on a void method.

moozzyk · 2017-05-19T19:33:54Z

client-ts/Microsoft.AspNetCore.SignalR.Client.TS/Observable.ts

+ }
+
+ public next(item: T): void {
+ for (let observer of this.observers) {


nit: these loops could be just forEach

moozzyk · 2017-05-19T19:34:40Z

samples/SocketsSample/wwwroot/streaming.html

+ invocationCounter += 1;
+ addLine('resultsList', `running ${method}(${id}) ...`);
+ connection.stream(method, 10, (Math.random() * 5) * 200).subscribe({
+ closed: false,


Needed at all? or should be just null because we don't maintain it.

It's part of the interface, but I believe it's optional.

moozzyk · 2017-05-19T19:42:20Z

src/Microsoft.AspNetCore.SignalR/Internal/AsyncEnumeratorAdapters.cs

+ var channel = Channel.CreateUnbounded<object>();
+ var cancellationTokenSource = new CancellationTokenSource();
+
+ var subscription = observable.Subscribe(new ChannelObserver<T>(channel.Out, cancellationTokenSource.Token));


Why not just CancellationToken.None instead of cts.Token?

Because at one point I planned to cancel it, but it turns out there's nowhere to do so. Will fix :)

You actually do need to make cancellation work here. I was just thinking about this a bit. The token here needs to represent the connection lifetime. If you're streaming and the connection dies, we need to notify something. There are some challenges though:

If the particular stream was created as part of that invocation, then completing the stream makes sense if the connection goes away.

If the stream is shared, you can't assume that ending a single connection should kill the stream.

This means that we need to expose a cancellation token on the connection so that the hub can choose what to do when a connection goes away. We can also think about ways to make things a bit more automatic (something declarative).

davidfowl · 2017-05-20T07:20:12Z

src/Microsoft.AspNetCore.SignalR/Internal/AsyncEnumeratorAdapters.cs

+ if (!_output.WaitToWriteAsync(_cancellationToken).Result)
+ {
+ // Channel was closed.
+ throw new InvalidOperationException("Output channel was closed");


Won't this crash the process?

It will crash the thing that drives the Observer, which depends on the underlying implementation of IObservable. We could suppress the exception and just drop items I guess.

davidfowl · 2017-05-20T07:20:56Z

test/Microsoft.AspNetCore.SignalR.Tests/HubEndpointTests.cs

@@ -518,6 +600,63 @@ private IServiceProvider CreateServiceProvider(Action<ServiceCollection> addServ
 return services.BuildServiceProvider();
 }

+ public class StreamingHub : TestHub
+ {
+ [return: Streaming]


analogrelay · 2017-05-22T23:05:30Z

🆙 📅 and rebase. I got the C# client support added and tests in place for it and the TS client.

davidfowl · 2017-05-23T07:48:04Z

build/dependencies.props

@@ -12,6 +12,7 @@
 <RedisVersion>1.2.3</RedisVersion>
 <TestSdkVersion>15.3.0-*</TestSdkVersion>
 <XunitVersion>2.3.0-beta2-*</XunitVersion>
+ <RxVersion>3.1.1</RxVersion>


Do we need permission to use this?

/cc @Eilon

Shoot, I meant to wait to push this until I got confirmation from @Eilon, but I've already started the process with him.

Got approval from @Eilon

davidfowl · 2017-05-23T09:02:00Z

src/Microsoft.AspNetCore.SignalR.Client/InvocationRequest.cs

+ public CancellationToken CancellationToken { get; }
+ public string InvocationId { get; }
+
+ public Task<object> Task => _completionSource?.Task;


A null Task is pretty crappy. Make it return a completed task if there's nothing.

davidfowl · 2017-05-23T09:02:17Z

src/Microsoft.AspNetCore.SignalR.Client/InvocationRequest.cs

+ public InvocationRequest(CancellationToken cancellationToken, Type resultType, string invocationId, ILoggerFactory loggerFactory, bool streaming)
+ {
+ _logger = loggerFactory.CreateLogger<InvocationRequest>();
+ _cancellationTokenRegistration = cancellationToken.Register(() => _completionSource.TrySetCanceled());


Remove allocation.

davidfowl · 2017-05-23T09:02:54Z

src/Microsoft.AspNetCore.SignalR.Client/InvocationRequest.cs

+
+ public void StreamItem(object item)
+ {
+ if(_streaming)


davidfowl · 2017-05-23T09:04:19Z

src/Microsoft.AspNetCore.SignalR.Client/InvocationRequest.cs

+ _completionSource.TrySetCanceled();
+ }
+
+ _cancellationTokenRegistration.Dispose();


We need to make sure things like this don't dead lock (because dispose waits on cancel callbacks to finish).

The TCS is set to run continuations asynchronously, and firing that CTS is the only cancel callback.

davidfowl · 2017-05-23T09:07:19Z

src/Microsoft.AspNetCore.SignalR/HubEndPoint.cs

+
+ private async Task StreamResultsAsync(string invocationId, Connection connection, IHubProtocol protocol, IAsyncEnumerator<object> enumerator)
+ {
+ // TODO: Cancellation?


davidfowl · 2017-05-26T01:58:56Z

I think I like changing the client representation to Channel for now (on both the server and client). I think we should commit what you have in this PR and keep iterating.

analogrelay · 2017-05-30T16:05:13Z

(on both the server and client)

The server representation is actually IAsyncEnumerator<T> currently, so it wouldn't need to change.

…reaming

analogrelay · 2017-05-30T21:34:09Z

Rebased and reworked the client to use Channel as the primitive for Streaming. Will merge when I have green builds (as per @davidfowl 's comment), and we can iterate on it moving forward.

moozzyk · 2017-05-30T22:45:25Z

src/Microsoft.AspNetCore.SignalR.Client/InvocationRequest.cs

- _subject.TryOnNext(item);
+ while(!_channel.Out.TryWrite(item))
+ {
+ if(!await _channel.Out.WaitToWriteAsync())


nit: spaces (and on ln. 99)

moozzyk · 2017-05-30T23:04:03Z

src/Microsoft.AspNetCore.SignalR.Client/HubConnection.cs

@@ -115,7 +116,7 @@ public void On(string methodName, Type[] parameterTypes, Action<object[]> handle
 _handlers.AddOrUpdate(methodName, invocationHandler, (_, __) => invocationHandler);
 }

- public IObservable<object> Stream(string methodName, Type returnType, CancellationToken cancellationToken, params object[] args)
+ public ReadableChannel<object> Stream(string methodName, Type returnType, CancellationToken cancellationToken, params object[] args)
 {
 var irq = InvocationRequest.Stream(cancellationToken, returnType, GetNextId(), _loggerFactory, out var observable);


nit: rename observable to channel

moozzyk · 2017-05-30T23:20:13Z

src/Microsoft.AspNetCore.SignalR.Client/HubConnection.cs

@@ -203,7 +204,7 @@ private void OnDataReceived(byte[] data, MessageType messageType)
 _logger.LogWarning("Dropped unsolicited Stream Item message for invocation '{invocationId}'", streamItem.InvocationId);
 return;
 }
- DispatchInvocationStreamItem(streamItem, irq);
+ DispatchInvocationStreamItemAsync(streamItem, irq);


I think this introduces a race which can result in items not being reported in order. We might need a queue for this.

If we want to consider ordering of streamed items, that's a whole new design concept as the frames could get reordered in transit (so it doesn't even matter how we queue on the client). It's not necessarily required, as the user can stream items tagged with an order and do buffering.

In what circumstances would frames be reordered in transit?

moozzyk · 2017-05-30T23:23:59Z

src/Microsoft.AspNetCore.SignalR.Client/HubConnection.cs

 {
 _logger.LogTrace("Received StreamItem for Invocation #{invocationId}", streamItem.InvocationId);

 if (irq.CancellationToken.IsCancellationRequested)
 {
 _logger.LogTrace("Canceling dispatch of StreamItem message for Invocation {invocationId}. The invocation was cancelled.", irq.InvocationId);
 }
- else
+ else if (!await irq.StreamItem(streamItem.Item))


Can this throw?

Only in the Streaming case, if someone else closes the write end of the channel (which only we control). I'll add some guard code though since this runs in a background thread.

Thanks - I was afraid of an unhandled exception on a background thread which would crash the process and which could not be caught/handled in any way.

davidfowl · 2017-05-31T00:39:53Z

src/Microsoft.AspNetCore.SignalR.Client/InvocationRequest.cs

+ _completionSource.TrySetException(new InvalidOperationException("Streaming methods must be invoked using HubConnection.Stream"));
+
+ // We "delivered" the stream item successfully as far as the caller cares
+ return Task.FromResult(true);


This isn't cached

Boo ... https://source.dot.net/#System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncMethodBuilder.cs,b003e738047b6fd3,references

Double Boo... https://source.dot.net/#System.Private.CoreLib/src/System/Threading/Tasks/future.cs,98

davidfowl · 2017-05-31T12:58:54Z

Weird MSBuild hang:

  Microsoft.AspNetCore.SignalR.Client.TS -> /home/travis/build/aspnet/SignalR/client-ts/Microsoft.AspNetCore.SignalR.Client.TS/bin/Release/netstandard2.0/Microsoft.AspNetCore.SignalR.Client.TS.dll
MSBUILD : error MSB4166: Child node "32" exited prematurely. Shutting down. Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt.
/home/travis/build/aspnet/SignalR/client-ts/Microsoft.AspNetCore.SignalR.Client.TS/Microsoft.AspNetCore.SignalR.Client.TS.csproj(27,5): warning MSB5021: "sh" and its child processes are being terminated in order to cancel the build.
/home/travis/build/aspnet/SignalR/client-ts/Microsoft.AspNetCore.SignalR.Client.TS/Microsoft.AspNetCore.SignalR.Client.TS.csproj(27,5): warning MSB4220: Waiting for the currently executing task "Exec" to cancel.
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/Roslyn/Microsoft.CSharp.Core.targets(71,5): warning MSB5021: "bash" and its child processes are being terminated in order to cancel the build. [/home/travis/build/aspnet/SignalR/samples/WebSocketSample/WebSocketSample.csproj]
  Microsoft.AspNetCore.Sockets.Common -> /home/travis/build/aspnet/SignalR/src/Microsoft.AspNetCore.Sockets.Common/bin/Release/netstandard1.3/Microsoft.AspNetCore.Sockets.Common.dll
  Microsoft.Extensions.WebSockets.Internal -> /home/travis/build/aspnet/SignalR/src/Microsoft.Extensions.WebSockets.Internal/bin/Release/netstandard2.0/Microsoft.Extensions.WebSockets.Internal.dll
  WebSocketSample -> /home/travis/build/aspnet/SignalR/samples/WebSocketSample/bin/Release/netcoreapp2.0/WebSocketSample.dll
AutobahnTests.cs(26,26): warning xUnit1004: Test methods should not be skipped [/home/travis/build/aspnet/SignalR/test/Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest/Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest.csproj]
  Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest -> /home/travis/build/aspnet/SignalR/test/Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest/bin/Release/netcoreapp2.0/Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest.dll
Build FAILED.
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/NuGet.targets(98,5): warning : Detected package downgrade: NETStandard.Library from 2.0.0-preview2-25316-01 to 1.6.1  [/home/travis/build/aspnet/SignalR/.build/KoreBuild.proj]
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/NuGet.targets(98,5): warning :  Microsoft.AspNetCore.SignalR.Client (>= 1.0.0-preview2-t004899032) -> Microsoft.AspNetCore.Sockets.Client (>= 1.0.0-preview2-t004899032) -> Microsoft.Extensions.Logging.Abstractions (>= 2.0.0-preview2-25326) -> NETStandard.Library (>= 2.0.0-preview2-25316-01)  [/home/travis/build/aspnet/SignalR/.build/KoreBuild.proj]
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/NuGet.targets(98,5): warning :  Microsoft.AspNetCore.SignalR.Client (>= 1.0.0-preview2-t004899032) -> NETStandard.Library (>= 1.6.1) [/home/travis/build/aspnet/SignalR/.build/KoreBuild.proj]
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/NuGet.targets(98,5): warning : Detected package downgrade: NETStandard.Library from 2.0.0-preview2-25316-01 to 1.6.1  [/home/travis/build/aspnet/SignalR/.build/KoreBuild.proj]
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/NuGet.targets(98,5): warning :  Microsoft.AspNetCore.Sockets.Client (>= 1.0.0-preview2-t004899032) -> Microsoft.Extensions.Logging.Abstractions (>= 2.0.0-preview2-25326) -> NETStandard.Library (>= 2.0.0-preview2-25316-01)  [/home/travis/build/aspnet/SignalR/.build/KoreBuild.proj]
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/NuGet.targets(98,5): warning :  Microsoft.AspNetCore.Sockets.Client (>= 1.0.0-preview2-t004899032) -> NETStandard.Library (>= 1.6.1) [/home/travis/build/aspnet/SignalR/.build/KoreBuild.proj]
/home/travis/build/aspnet/SignalR/client-ts/Microsoft.AspNetCore.SignalR.Client.TS/Microsoft.AspNetCore.SignalR.Client.TS.csproj(27,5): warning MSB5021: "sh" and its child processes are being terminated in order to cancel the build.
/home/travis/build/aspnet/SignalR/client-ts/Microsoft.AspNetCore.SignalR.Client.TS/Microsoft.AspNetCore.SignalR.Client.TS.csproj(27,5): warning MSB4220: Waiting for the currently executing task "Exec" to cancel.
/home/travis/.dotnet/sdk/2.0.0-preview2-006127/Roslyn/Microsoft.CSharp.Core.targets(71,5): warning MSB5021: "bash" and its child processes are being terminated in order to cancel the build. [/home/travis/build/aspnet/SignalR/samples/WebSocketSample/WebSocketSample.csproj]
AutobahnTests.cs(26,26): warning xUnit1004: Test methods should not be skipped [/home/travis/build/aspnet/SignalR/test/Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest/Microsoft.AspNetCore.WebSockets.Internal.ConformanceTest.csproj]
MSBUILD : error MSB4166: Child node "32" exited prematurely. Shutting down. Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt.
    6 Warning(s)
    1 Error(s)
Time Elapsed 00:13:48.97
'dotnet msbuild @/home/travis/build/aspnet/SignalR/artifacts/msbuild/msbuild.rsp' failed with exit code 1
The command "./build.sh" exited with 1.

moozzyk · 2017-05-31T21:21:35Z

I have seen this happen twice yesterday. I don't know how to get this file (or if it is even possible): Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt.. I wonder if this: This job ran on our container-based trusty beta can be the culprit.

analogrelay · 2017-06-01T18:00:44Z

We've been running on the container-based infrastructure across the platform for a while now and problems haven't been that consistent. Plus, MSBuild should work in containers :).

moozzyk · 2017-06-01T18:11:26Z

I agree in general. I was just wondering if because it's beta it still may have some issues where a process can be randomly killed which would affect the build.

analogrelay requested review from davidfowl, moozzyk, mikaelm12 and BrennanConroy May 18, 2017 19:36

dnfclas added the cla-already-signed label May 18, 2017

analogrelay changed the title ~~Streaming support~~ Fix #324 by adding streaming support to the server May 18, 2017

davidfowl reviewed May 19, 2017

View reviewed changes

BrennanConroy reviewed May 19, 2017

View reviewed changes

moozzyk reviewed May 19, 2017

View reviewed changes

davidfowl reviewed May 20, 2017

View reviewed changes

analogrelay force-pushed the anurse/324-streaming branch from e9660f4 to 2f6790b Compare May 22, 2017 23:02

davidfowl reviewed May 23, 2017

View reviewed changes

davidfowl approved these changes May 26, 2017

View reviewed changes

analogrelay and others added 15 commits May 30, 2017 10:15

fix #324 by adding streaming support to the server

f7f301d

fix test

ef795ee

fix Channel streaming and javascript sample

053f025

some test simplification to prepare for adding ts client tests for st…

96feea2

…reaming

stash

c04aa55

add tests for TypeScript client and streaming

f08ad5f

add C# client support and tests

4972a53

pr feedback

e76db0b

fix build

01b61d2

remove bogus cts

cf5f4ed

update comment to reference bug

ed2516b

copyrights and usings

278fa7e

loggers

bd8e7ea

pr feedback

8cde8c3

switch client API to use channel instead of Rx

16b03e9

analogrelay force-pushed the anurse/324-streaming branch from 479e832 to 16b03e9 Compare May 30, 2017 21:33

remove unused type

58b74c6

moozzyk reviewed May 30, 2017

View reviewed changes

davidfowl reviewed May 31, 2017

View reviewed changes

pr feedback

54f8a6b

analogrelay merged commit 263dd0e into dev May 31, 2017

analogrelay deleted the anurse/324-streaming branch December 13, 2017 00:39

Fix #324 by adding streaming support to the server #461

Fix #324 by adding streaming support to the server #461

Conversation

analogrelay commented May 18, 2017

davidfowl May 19, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidfowl commented May 19, 2017

davidfowl commented May 19, 2017 • edited Loading

analogrelay commented May 19, 2017 • edited Loading

analogrelay commented May 19, 2017 • edited Loading

analogrelay commented May 19, 2017

davidfowl commented May 19, 2017 • edited Loading

analogrelay commented May 19, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

analogrelay commented May 19, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

analogrelay commented May 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

analogrelay May 23, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidfowl commented May 26, 2017

analogrelay commented May 30, 2017

analogrelay commented May 30, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidfowl commented May 31, 2017

moozzyk commented May 31, 2017

analogrelay commented Jun 1, 2017

moozzyk commented Jun 1, 2017

davidfowl May 19, 2017 •

edited

Loading

davidfowl commented May 19, 2017 •

edited

Loading

analogrelay commented May 19, 2017 •

edited

Loading

analogrelay commented May 19, 2017 •

edited

Loading

davidfowl commented May 19, 2017 •

edited

Loading

analogrelay commented May 19, 2017 •

edited

Loading

analogrelay May 23, 2017 •

edited

Loading