{"id":13430552,"url":"https://github.com/reactive-streams/reactive-streams-dotnet","last_synced_at":"2025-05-05T22:36:14.575Z","repository":{"id":48666705,"uuid":"58304807","full_name":"reactive-streams/reactive-streams-dotnet","owner":"reactive-streams","description":"Reactive Streams for .NET","archived":false,"fork":false,"pushed_at":"2021-07-15T05:37:31.000Z","size":2260,"stargazers_count":200,"open_issues_count":10,"forks_count":28,"subscribers_count":20,"default_branch":"master","last_synced_at":"2025-03-31T00:23:42.599Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit-0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/reactive-streams.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-05-08T09:17:54.000Z","updated_at":"2025-01-30T12:46:25.000Z","dependencies_parsed_at":"2022-09-07T18:22:14.067Z","dependency_job_id":null,"html_url":"https://github.com/reactive-streams/reactive-streams-dotnet","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/reactive-streams%2Freactive-streams-dotnet","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/reactive-streams%2Freactive-streams-dotnet/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/reactive-streams%2Freactive-streams-dotnet/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/reactive-streams%2Freactive-streams-dotnet/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/reactive-streams","download_url":"https://codeload.github.com/reactive-streams/reactive-streams-dotnet/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252587605,"owners_count":21772501,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T02:00:55.123Z","updated_at":"2025-05-05T22:36:14.557Z","avatar_url":"https://github.com/reactive-streams.png","language":"C#","funding_links":[],"categories":["Frameworks, Libraries and Tools","框架, 库和工具","Functional Programming"],"sub_categories":["Functional Programming","响应式编程"],"readme":"# Reactive Streams .NET#\n\nThe purpose of Reactive Streams is to provide a standard for asynchronous stream processing with non-blocking backpressure.\n\nThe latest release is [available on NuGet](https://www.nuget.org/packages/Reactive.Streams).\n\nTo install Reactive Streams, run the following command in the Package Manager Console\n\n```\nPM\u003e Install-Package Reactive.Streams\n```\n\n## Goals, Design and Scope ##\n\nHandling streams of data—especially “live” data whose volume is not predetermined—requires special care in an asynchronous system. The most prominent issue is that resource consumption needs to be carefully controlled such that a fast data source does not overwhelm the stream destination. Asynchrony is needed in order to enable the parallel use of computing resources, on collaborating network hosts or multiple CPU cores within a single machine.\n\nThe main goal of Reactive Streams is to govern the exchange of stream data across an asynchronous boundary – think passing elements on to another thread or thread-pool — while ensuring that the receiving side is not forced to buffer arbitrary amounts of data. In other words, backpressure is an integral part of this model in order to allow the queues which mediate between threads to be bounded. The benefits of asynchronous processing would be negated if the communication of backpressure were synchronous (see also the [Reactive Manifesto](http://reactivemanifesto.org/)), therefore care has been taken to mandate fully non-blocking and asynchronous behavior of all aspects of a Reactive Streams implementation.\n\nIt is the intention of this specification to allow the creation of many conforming implementations, which by virtue of abiding by the rules will be able to interoperate smoothly, preserving the aforementioned benefits and characteristics across the whole processing graph of a stream application.\n\nIt should be noted that the precise nature of stream manipulations (transformation, splitting, merging, etc.) is not covered by this specification. Reactive Streams are only concerned with mediating the stream of data between different [API Components](#api-components). In their development care has been taken to ensure that all basic ways of combining streams can be expressed.\n\nIn summary, Reactive Streams .NET is a standard and specification for Stream-oriented libraries for .NET that\n\n - process a potentially unbounded number of elements\n - in sequence,\n - asynchronously passing elements between components,\n - with mandatory non-blocking backpressure.\n\nThe Reactive Streams specification consists of the following parts:\n\n***The API*** specifies the types to implement Reactive Streams and achieve interoperability between different implementations.\n\n***The Technology Compatibility Kit (TCK)*** is a standard test suite for conformance testing of implementations.\n\nImplementations are free to implement additional features not covered by the specification as long as they conform to the API requirements and pass the tests in the TCK.\n\n### API Components ###\n\nThe API consists of the following components that are required to be provided by Reactive Stream implementations:\n\n1. IPublisher\n2. ISubscriber\n3. ISubscription\n4. IProcessor\n\nAn *IPublisher* is a provider of a potentially unbounded number of sequenced elements, publishing them according to the demand received from its ISubscriber(s).\n\nIn response to a call to `IPublisher.Subscribe(ISubscriber)` the possible invocation sequences for methods on the `ISubscriber` are given by the following protocol:\n\n```\nonSubscribe onNext* (onError | onComplete)?\n```\n\nThis means that `onSubscribe` is always signalled,\nfollowed by a possibly unbounded number of `onNext` signals (as requested by `ISubscriber`) followed by an `onError` signal if there is a failure, or an `onComplete` signal when no more elements are available—all as long as the `ISubscription` is not cancelled.\n\n#### NOTES\n\n- The specifications below use binding words in capital letters from https://www.ietf.org/rfc/rfc2119.txt\n- The terms `emit`, `signal` or `send` are interchangeable. The specifications below will use `signal`.\n- The terms `synchronously` or `synchronous` refer to executing in the calling `Thread`.\n- The term \"return normally\" means \"only throws exceptions that are explicitly allowed by the rule\".\n\n### SPECIFICATION\n\n#### 1. IPublisher ([Code](https://github.com/reactive-streams/reactive-streams-dotnet/blob/master/src/api/Reactive.Streams/IPublisher.cs))\n\n```c#\npublic interface IPublisher\u003cout T\u003e {\n    void Subscribe(ISubscriber\u003cT\u003e subscriber);\n}\n````\n\n| ID                        | Rule                                                                                                   |\n| ------------------------- | ------------------------------------------------------------------------------------------------------ |\n| \u003ca name=\"1.1\"\u003e1\u003c/a\u003e       | The total number of `onNext` signals sent by an `IPublisher` to an `ISubscriber` MUST be less than or equal to the total number of elements requested by that `ISubscriber`´s `ISubscription` at all times. |\n| \u003ca name=\"1.2\"\u003e2\u003c/a\u003e       | An `IPublisher` MAY signal less `onNext` than requested and terminate the `ISubscription` by calling `OnComplete` or `OnError`. |\n| \u003ca name=\"1.3\"\u003e3\u003c/a\u003e       | `onSubscribe`, `onNext`, `onError` and `onComplete` signaled to an `ISubscriber` MUST be signaled sequentially (no concurrent notifications). |\n| \u003ca name=\"1.4\"\u003e4\u003c/a\u003e       | If an `IPublisher` fails it MUST signal an `onError`. |\n| \u003ca name=\"1.5\"\u003e5\u003c/a\u003e       | If an `IPublisher` terminates successfully (finite stream) it MUST signal an `onComplete`. |\n| \u003ca name=\"1.6\"\u003e6\u003c/a\u003e       | If an `IPublisher` signals either `onError` or `onComplete` on an `ISubscriber`, that `ISubscriber`’s `ISubscription` MUST be considered cancelled. |\n| \u003ca name=\"1.7\"\u003e7\u003c/a\u003e       | Once a terminal state has been signaled (`onError`, `onComplete`) it is REQUIRED that no further signals occur. |\n| \u003ca name=\"1.8\"\u003e8\u003c/a\u003e       | If an `ISubscription` is cancelled its `ISubscriber` MUST eventually stop being signaled. |\n| \u003ca name=\"1.9\"\u003e9\u003c/a\u003e       | `IPublisher.Subscribe` MUST call `OnSubscribe` on the provided `ISubscriber` prior to any other signals to that `ISubscriber` and MUST return normally, except when the provided `ISubscriber` is `null` in which case it MUST throw a `System.ArgumentNullException` to the caller, for all other situations [[1]](#footnote-1-1) the only legal way to signal failure (or reject the `ISubscriber`) is by calling `OnError` (after calling `OnSubscribe`). |\n| \u003ca name=\"1.10\"\u003e10\u003c/a\u003e     | `IPublisher.Subscribe` MAY be called as many times as wanted but MUST be with a different `ISubscriber` each time [see [2.12](#2.12)]. |\n| \u003ca name=\"1.11\"\u003e11\u003c/a\u003e     | An `IPublisher` MAY support multiple `ISubscriber`s and decides whether each `ISubscription` is unicast or multicast. |\n\n[\u003ca name=\"footnote-1-1\"\u003e1\u003c/a\u003e] :  A stateful IPublisher can be overwhelmed, bounded by a finite number of underlying resources, exhausted, shut-down or in a failed state.\n\n#### 2. ISubscriber ([Code](https://github.com/reactive-streams/reactive-streams-dotnet/blob/master/src/api/Reactive.Streams/ISubscriber.cs))\n\n```c#\npublic interface ISubscriber\u003cin T\u003e {\n    public void OnSubscribe(ISubscription subscription);\n    public void OnNext(T element);\n    public void OnError(Exception cause);\n    public void OnComplete();\n}\n````\n\n| ID                        | Rule                                                                                                   |\n| ------------------------- | ------------------------------------------------------------------------------------------------------ |\n| \u003ca name=\"2.1\"\u003e1\u003c/a\u003e       | An `ISubscriber` MUST signal demand via `ISubscription.Request(long n)` to receive `onNext` signals. |\n| \u003ca name=\"2.2\"\u003e2\u003c/a\u003e       | If an `ISubscriber` suspects that its processing of signals will negatively impact its `IPublisher`'s responsivity, it is RECOMMENDED that it asynchronously dispatches its signals. |\n| \u003ca name=\"2.3\"\u003e3\u003c/a\u003e       | `ISubscriber.OnComplete()` and `ISubscriber.OnError(Exception cause)` MUST NOT call any methods on the `ISubscription` or the `IPublisher`. |\n| \u003ca name=\"2.4\"\u003e4\u003c/a\u003e       | `ISubscriber.OnComplete()` and `ISubscriber.OnError(Exception cause)` MUST consider the ISubscription cancelled after having received the signal. |\n| \u003ca name=\"2.5\"\u003e5\u003c/a\u003e       | An `ISubscriber` MUST call `ISubscription.Cancel()` on the given `ISubscription` after an `onSubscribe` signal if it already has an active `ISubscription`. |\n| \u003ca name=\"2.6\"\u003e6\u003c/a\u003e       | An `ISubscriber` MUST call `ISubscription.Cancel()` if it is no longer valid to the `IPublisher` without the `IPublisher` having signaled `onError` or `onComplete`. |\n| \u003ca name=\"2.7\"\u003e7\u003c/a\u003e       | An `ISubscriber` MUST ensure that all calls on its `ISubscription` take place from the same thread or provide for respective external synchronization. |\n| \u003ca name=\"2.8\"\u003e8\u003c/a\u003e       | An `ISubscriber` MUST be prepared to receive one or more `onNext` signals after having called `ISubscription.Cancel()` if there are still requested elements pending [see [3.12](#3.12)]. `ISubscription.Cancel()` does not guarantee to perform the underlying cleaning operations immediately. |\n| \u003ca name=\"2.9\"\u003e9\u003c/a\u003e       | An `ISubscriber` MUST be prepared to receive an `onComplete` signal with or without a preceding `ISubscription.Request(long n)` call. |\n| \u003ca name=\"2.10\"\u003e10\u003c/a\u003e     | An `ISubscriber` MUST be prepared to receive an `onError` signal with or without a preceding `ISubscription.Request(long n)` call. |\n| \u003ca name=\"2.11\"\u003e11\u003c/a\u003e     | An `ISubscriber` MUST make sure that all calls on its `OnXXX` methods happen-before [[1]](#footnote-2-1) the processing of the respective signals. I.e. the ISubscriber must take care of properly publishing the signal to its processing logic. |\n| \u003ca name=\"2.12\"\u003e12\u003c/a\u003e     | `ISubscriber.OnSubscribe` MUST be called at most once for a given `ISubscriber` (based on object equality). |\n| \u003ca name=\"2.13\"\u003e13\u003c/a\u003e     | Calling `OnSubscribe`, `OnNext`, `OnError` or `OnComplete` MUST return normally except when any provided parameter is `null` in which case it MUST throw a `System.ArgumentNullException` to the caller, for all other situations the only legal way for an `ISubscriber` to signal failure is by cancelling its `ISubscription`. In the case that this rule is violated, any associated `ISubscription` to the `ISubscriber` MUST be considered as cancelled, and the caller MUST raise this error condition in a fashion that is adequate for the runtime environment. |\n\n[\u003ca name=\"footnote-2-1\"\u003e1\u003c/a\u003e] : See JMM definition of Happen-Before in section 17.4.5. on http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html\n\n#### 3. ISubscription ([Code](https://github.com/reactive-streams/reactive-streams-dotnet/blob/master/src/api/Reactive.Streams/ISubscription.cs))\n\n```c#\npublic interface ISubscription {\n    public void Request(long n);\n    public void Cancel();\n}\n````\n\n| ID                        | Rule                                                                                                   |\n| ------------------------- | ------------------------------------------------------------------------------------------------------ |\n| \u003ca name=\"3.1\"\u003e1\u003c/a\u003e       | `ISubscription.Request` and `ISubscription.Cancel` MUST only be called inside of its `ISubscriber` context. An `ISubscription` represents the unique relationship between an `ISubscriber` and an `IPublisher` [see [2.12](#2.12)]. |\n| \u003ca name=\"3.2\"\u003e2\u003c/a\u003e       | The `ISubscription` MUST allow the `ISubscriber` to call `ISubscription.Request` synchronously from within `OnNext` or `OnSubscribe`. |\n| \u003ca name=\"3.3\"\u003e3\u003c/a\u003e       | `ISubscription.Request` MUST place an upper bound on possible synchronous recursion between `IPublisher` and `ISubscriber`[[1](#footnote-3-1)]. |\n| \u003ca name=\"3.4\"\u003e4\u003c/a\u003e       | `ISubscription.Request` SHOULD respect the responsivity of its caller by returning in a timely manner[[2](#footnote-3-2)]. |\n| \u003ca name=\"3.5\"\u003e5\u003c/a\u003e       | `ISubscription.Cancel` MUST respect the responsivity of its caller by returning in a timely manner[[2](#footnote-3-2)], MUST be idempotent and MUST be thread-safe. |\n| \u003ca name=\"3.6\"\u003e6\u003c/a\u003e       | After the `ISubscription` is cancelled, additional `ISubscription.Request(long n)` MUST be NOPs. |\n| \u003ca name=\"3.7\"\u003e7\u003c/a\u003e       | After the `ISubscription` is cancelled, additional `ISubscription.Cancel()` MUST be NOPs. |\n| \u003ca name=\"3.8\"\u003e8\u003c/a\u003e       | While the `ISubscription` is not cancelled, `ISubscription.Request(long n)` MUST register the given number of additional elements to be produced to the respective subscriber. |\n| \u003ca name=\"3.9\"\u003e9\u003c/a\u003e       | While the `ISubscription` is not cancelled, `ISubscription.Request(long n)` MUST signal `onError` with a `System.ArgumentException` if the argument is \u003c= 0. The cause message MUST include a reference to this rule and/or quote the full rule. |\n| \u003ca name=\"3.10\"\u003e10\u003c/a\u003e     | While the `ISubscription` is not cancelled, `ISubscription.Request(long n)` MAY synchronously call `OnNext` on this (or other) subscriber(s). |\n| \u003ca name=\"3.11\"\u003e11\u003c/a\u003e     | While the `ISubscription` is not cancelled, `ISubscription.Request(long n)` MAY synchronously call `OnComplete` or `OnError` on this (or other) subscriber(s). |\n| \u003ca name=\"3.12\"\u003e12\u003c/a\u003e     | While the `ISubscription` is not cancelled, `ISubscription.Cancel()` MUST request the `IPublisher` to eventually stop signaling its `ISubscriber`. The operation is NOT REQUIRED to affect the `ISubscription` immediately. |\n| \u003ca name=\"3.13\"\u003e13\u003c/a\u003e     | While the `ISubscription` is not cancelled, `ISubscription.Cancel()` MUST request the `IPublisher` to eventually drop any references to the corresponding subscriber. Re-subscribing with the same `ISubscriber` object is discouraged [see [2.12](#2.12)], but this specification does not mandate that it is disallowed since that would mean having to store previously cancelled subscriptions indefinitely. |\n| \u003ca name=\"3.14\"\u003e14\u003c/a\u003e     | While the `ISubscription` is not cancelled, calling `ISubscription.Cancel` MAY cause the `IPublisher`, if stateful, to transition into the `shut-down` state if no other `ISubscription` exists at this point [see [1.9](#1.9)].\n| \u003ca name=\"3.15\"\u003e15\u003c/a\u003e     | Calling `ISubscription.Cancel` MUST return normally. The only legal way to signal failure to an `ISubscriber` is via the `OnError` method. |\n| \u003ca name=\"3.16\"\u003e16\u003c/a\u003e     | Calling `ISubscription.Request` MUST return normally. The only legal way to signal failure to an `ISubscriber` is via the `OnError` method. |\n| \u003ca name=\"3.17\"\u003e17\u003c/a\u003e     | An `ISubscription` MUST support an unbounded number of calls to Request and MUST support a demand (sum requested - sum delivered) up to 2^63-1 (`System.Int64.MaxValue`). A demand equal or greater than 2^63-1 (`System.Int64.MaxValue`) MAY be considered by the `IPublisher` as “effectively unbounded”[[3](#footnote-3-3)]. |\n\n[\u003ca name=\"footnote-3-1\"\u003e1\u003c/a\u003e] : An example for undesirable synchronous, open recursion would be `ISubscriber.OnNext` -\u003e `ISubscription.Request` -\u003e `ISubscriber.OnNext` -\u003e …, as it very quickly would result in blowing the calling Thread´s stack.\n\n[\u003ca name=\"footnote-3-2\"\u003e2\u003c/a\u003e] : Avoid heavy computations and other things that would stall the caller´s thread of execution\n\n[\u003ca name=\"footnote-3-3\"\u003e3\u003c/a\u003e] : As it is not feasibly reachable with current or foreseen hardware within a reasonable amount of time (1 element per nanosecond would take 292 years) to fulfill a demand of 2^63-1, it is allowed for an `IPublisher` to stop tracking demand beyond this point.\n\nAn `ISubscription` is shared by exactly one `IPublisher` and one `ISubscriber` for the purpose of mediating the data exchange between this pair. This is the reason why the `Subscribe()` method does not return the created `ISubscription`, but instead returns `void`; the `ISubscription` is only passed to the `ISubscriber` via the `OnSubscribe` callback.\n\n#### 4.IProcessor ([Code](https://github.com/reactive-streams/reactive-streams-dotnet/blob/master/src/api/Reactive.Streams/IProcessor.cs))\n\n```c#\npublic interface IProcessor\u003cin T1, out T2\u003e : ISubscriber\u003cT1\u003e, IPublisher\u003cT2\u003e {\n}\n````\n\n| ID                       | Rule                                                                                                   |\n| ------------------------ | ------------------------------------------------------------------------------------------------------ |\n| \u003ca name=\"4.1\"\u003e1\u003c/a\u003e      | An `IProcessor` represents a processing stage—which is both an `ISubscriber` and an `IPublisher` and MUST obey the contracts of both. |\n| \u003ca name=\"4.2\"\u003e2\u003c/a\u003e      | An `IProcessor` MAY choose to recover an `onError` signal. If it chooses to do so, it MUST consider the `ISubscription` cancelled, otherwise it MUST propagate the `onError` signal to its ISubscribers immediately. |\n\nWhile not mandated, it can be a good idea to cancel an `IProcessors` upstream `ISubscription` when/if its last `ISubscriber` cancels their `ISubscription`,\nto let the cancellation signal propagate upstream.\n\n### Asynchronous vs Synchronous Processing ###\n\nThe Reactive Streams API prescribes that all processing of elements (`onNext`) or termination signals (`onError`, `onComplete`) MUST NOT *block* the `IPublisher`. However, each of the `On*` handlers can process the events synchronously or asynchronously.\n\nTake this example:\n\n```\nnioSelectorThreadOrigin map(f) filter(p) consumeTo(toNioSelectorOutput)\n```\n\nIt has an async origin and an async destination. Let's assume that both origin and destination are selector event loops. The `ISubscription.Request(n)` must be chained from the destination to the origin. This is now where each implementation can choose how to do this.\n\nThe following uses the pipe `|` character to signal async boundaries (queue and schedule) and `R#` to represent resources (possibly threads).\n\n```\nnioSelectorThreadOrigin | map(f) | filter(p) | consumeTo(toNioSelectorOutput)\n-------------- R1 ----  | - R2 - | -- R3 --- | ---------- R4 ----------------\n```\n\nIn this example each of the 3 consumers, `map`, `filter` and `consumeTo` asynchronously schedule the work. It could be on the same event loop (trampoline), separate threads, whatever.\n\n```\nnioSelectorThreadOrigin map(f) filter(p) | consumeTo(toNioSelectorOutput)\n------------------- R1 ----------------- | ---------- R2 ----------------\n```\n\nHere it is only the final step that asynchronously schedules, by adding work to the NioSelectorOutput event loop. The `map` and `filter` steps are synchronously performed on the origin thread.\n\nOr another implementation could fuse the operations to the final consumer:\n\n```\nnioSelectorThreadOrigin | map(f) filter(p) consumeTo(toNioSelectorOutput)\n--------- R1 ---------- | ------------------ R2 -------------------------\n```\n\nAll of these variants are \"asynchronous streams\". They all have their place and each has different tradeoffs including performance and implementation complexity.\n\nThe Reactive Streams contract allows implementations the flexibility to manage resources and scheduling and mix asynchronous and synchronous processing within the bounds of a non-blocking, asynchronous, dynamic push-pull stream.\n\nIn order to allow fully asynchronous implementations of all participating API elements—`IPublisher`/`ISubscription`/`ISubscriber`/`IProcessor`—all methods defined by these interfaces return `void`.\n\n### ISubscriber controlled queue bounds ###\n\nOne of the underlying design principles is that all buffer sizes are to be bounded and these bounds must be *known* and *controlled* by the subscribers. These bounds are expressed in terms of *element count* (which in turn translates to the invocation count of onNext). Any implementation that aims to support infinite streams (especially high output rate streams) needs to enforce bounds all along the way to avoid out-of-memory errors and constrain resource usage in general.\n\nSince back-pressure is mandatory the use of unbounded buffers can be avoided. In general, the only time when a queue might grow without bounds is when the publisher side maintains a higher rate than the subscriber for an extended period of time, but this scenario is handled by backpressure instead.\n\nQueue bounds can be controlled by a subscriber signaling demand for the appropriate number of elements. At any point in time the subscriber knows:\n\n - the total number of elements requested: `P`\n - the number of elements that have been processed: `N`\n\nThen the maximum number of elements that may arrive—until more demand is signaled to the IPublisher—is `P - N`. In the case that the subscriber also knows the number of elements B in its input buffer then this bound can be refined to `P - B - N`.\n\nThese bounds must be respected by a publisher independent of whether the source it represents can be backpressured or not. In the case of sources whose production rate cannot be influenced—for example clock ticks or mouse movement—the publisher must choose to either buffer or drop elements to obey the imposed bounds.\n\nISubscribers signaling a demand for one element after the reception of an element effectively implement a Stop-and-Wait protocol where the demand signal is equivalent to acknowledgement. By providing demand for multiple elements the cost of acknowledgement is amortized. It is worth noting that the subscriber is allowed to signal demand at any point in time, allowing it to avoid unnecessary delays between the publisher and the subscriber (i.e. keeping its input buffer filled without having to wait for full round-trips).\n\n## Legal\n\nThis project is a collaboration between engineers from Kaazing, Lightbend, Netflix, Pivotal, Red Hat, Twitter and many others. This project is licensed under MIT No Attribution (SPDX: MIT-0).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Freactive-streams%2Freactive-streams-dotnet","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Freactive-streams%2Freactive-streams-dotnet","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Freactive-streams%2Freactive-streams-dotnet/lists"}