Building gRPC client and server streaming with .NET 6

gRPC has matured into the go-to framework for low-latency service-to-service communication, and .NET 6 finally delivers a polished, performant streaming story across Windows, Linux, and macOS. Whether you are wiring a Sydney fintech to a live market data feed or pushing equipment telemetry from a Pilbara mining operation to a cloud control plane in Melbourne, the streaming primitives map cleanly onto real workloads running across Australian time zones. Engineers attending sessions at the C# Corner conference regularly cite streaming RPC as one of the practical skills they want to take back to their teams.

The combination of HTTP/2 framing, strongly typed contracts, and native async streams removes most of the boilerplate that used to plague WCF or raw socket code. Over the next several sections you will see how to define a proto file, generate server and client code, and build all three streaming patterns from scratch using nothing but the .NET 6 SDK and a handful of NuGet packages.

gRPC streaming patterns at a glance

Before writing any code, it helps to understand the four interaction shapes gRPC supports, because the choice of pattern shapes everything from threading to error handling.

Server streaming is the most common starting point because the server typically owns the data source. A Brisbane-based weather service pushing minute-by-minute radar frames to mobile clients is a textbook case: the client asks once, then receives an open-ended stream. Client streaming is rarer but valuable for telemetry ingestion, where hundreds of edge devices funnel readings into a central aggregator. Bidirectional streaming is the most powerful but also the trickiest to test, since both parties must agree on message boundaries and back-pressure semantics.

Defining the contract in a proto file

The proto file is the single source of truth for your service. With the .NET 6 SDK you no longer need to run protoc manually, because the Grpc.Tools package regenerates stubs on every build, which removes a whole class of "works on my machine" drift that has historically plagued polyglot teams.

Create a Protos/telemetry.proto file and use the stream keyword on the request or response fields to mark a streaming method:

syntax = "proto3";

option csharp_namespace = "Contoso.Telemetry";

service TelemetryService {
  rpc Subscribe(SubscribeRequest) returns (stream TelemetryEvent);
  rpc Publish(stream TelemetryEvent) returns (PublishSummary);
  rpc Chat(stream ChatMessage) returns (stream ChatMessage);
}

message SubscribeRequest {
  string asset_id = 1;
}

message TelemetryEvent {
  string asset_id = 1;
  double temperature = 2;
  int64 timestamp = 3;
}

In the .csproj file, set <Protobuf Include="Protos/telemetry.proto" GrpcServices="Both" /> so that both server and client base classes are generated. Developers in the Adelaide .NET user group have found this dual generation particularly handy when iterating on contracts across distributed teams, because a single dotnet build keeps both sides in lockstep without extra CI steps.

Building the server with IAsyncEnumerable

The server side of .NET 6 streaming reads naturally as an IAsyncEnumerable<T> method. There is no Task to await on each send, no manual WriteAsync loops, and no concerns about cancellation tokens leaking across handler boundaries.

public class TelemetryServiceImpl : TelemetryServiceBase
{
    private readonly ITelemetrySource _source;
    private readonly ILogger<TelemetryServiceImpl> _log;

    public TelemetryServiceImpl(ITelemetrySource source,
                                ILogger<TelemetryServiceImpl> log)
    {
        _source = source;
        _log = log;
    }

    public override async Task Subscribe(
        SubscribeRequest request,
        IServerStreamWriter<TelemetryEvent> responseStream,
        ServerCallContext context)
    {
        _log.LogInformation("Client subscribed to {Asset}", request.AssetId);

        await foreach (var evt in _source.StreamAsync(request.AssetId,
                                                     context.CancellationToken))
        {
            await responseStream.WriteAsync(evt);
        }
    }
}

Register the service with builder.Services.AddGrpc() and map it with app.MapGrpcService<TelemetryServiceImpl>(). The cancellation token attached to ServerCallContext fires when the client disconnects, which is critical on the flaky satellite links common to remote Australian mine sites where a dropped TCP connection would otherwise leave a dangling task spinning forever and slowly exhaust the worker pool.

Writing the client and going bidirectional

The client side mirrors the server almost symmetrically, which is one of gRPC's underrated strengths. You call a method, get back a response stream, and iterate it like any other async sequence.

using var channel = GrpcChannel.ForAddress("https://api.contoso.com");
var client = new TelemetryService.TelemetryServiceClient(channel);

using var call = client.Subscribe(new SubscribeRequest { AssetId = "pump-42" });
await foreach (var evt in call.ResponseStream.ReadAllAsync())
{
    Console.WriteLine($"{evt.Timestamp}: {evt.Temperature}");
}

For bidirectional streaming the pattern inverts slightly: you own the request stream and read from the response stream concurrently. A common idiom is to spawn a producer task that writes requests into RequestStream while the main async loop reads from ResponseStream. Wrapping the producer in Channel<T> gives you back-pressure for free and avoids the memory bloat that hits hard during AEST market open when the Sydney Stock Exchange floods subscribers with order-book deltas.

Always dispose the call deterministically; the using block ensures the underlying HTTP/2 stream is closed cleanly, freeing the connection slot for the next caller. Pooling GrpcChannel instances across the process is also recommended, because channel creation is comparatively expensive and most production servers handle hundreds of concurrent streams on the same multiplexed connection. For very high-throughput gateways a GrpcChannelPool registered as a singleton keeps connection churn off the hot path.

Observability, deadlines, and production hardening

Streaming RPCs live or die on operational discipline. A unary call that hangs for sixty seconds is annoying; a streaming call that hangs forever is a resource leak waiting to happen across the entire fleet.

Set deadlines aggressively. A five-second deadline on Subscribe tells the client to give up rather than hold a thread indefinitely, which matters when your service is fronted by a load balancer in ap-southeast-2 and you cannot afford to starve the worker pool during a traffic spike. Combine deadlines with retry policies from Grpc.Net.Client and the Polly integration, but only retry idempotent unary calls; never blindly retry a streaming call that may have already processed half of the messages on the server.

Wire up OpenTelemetry early. The Grpc.Net.Client and Grpc.AspNetCore.Server packages emit spans and metrics out of the box, so a quick services.AddOpenTelemetry().WithTracing(t => t.AddGrpcClientInstrumentation().AddGrpcServerInstrumentation()) is enough to get distributed traces flowing into your observability stack. Local teams running Grafana and Loki on Kubernetes in Brisbane have reported that adding gRPC instrumentation cut their mean-time-to-diagnose for stuck streams from hours to minutes, especially when chasing cross-region latency between ap-southeast-2 and ap-southeast-4.

Finally, test with grpcurl and the in-memory test server from Grpc.Net.Client. Integration tests that spin up a TestServer with WebApplicationFactory let you assert that your enumerables complete correctly under cancellation, which is the single most common bug surface in streaming code. Once you are confident in the behaviour, the same code path deploys unchanged to an AKS cluster, an on-premises Windows Server, or a Raspberry Pi gateway in the field collecting readings from solar farms north of Cairns.