检测 IObservable 上的 IsAlive

发布于 2024-11-10 09:48:41 字数 751 浏览 2 评论 0原文

我正在编写一个函数 IsAlive 来获取 IObservable 和时间跨度,并返回 IObservable 规范使用案例是检测流媒体服务器是否仍在发送数据。

我为此提出了以下解决方案,但感觉它的工作原理并不是最清楚的。

public static IObservable<bool> IsAlive<T>(this IObservable<T> source, 
                                           TimeSpan timeout, 
                                           IScheduler sched)
{
    return source.Window(timeout, sched)
                 .Select(wind => wind.Any())
                 .SelectMany(a => a)
                 .DistinctUntilChanged();
}

有人有更好的方法吗?

供参考 - 以下是我尝试过的单元测试和现有方法: https://gist.github.com/997003

I'm writing a function IsAlive to take an IObservable<T>, and a timespan, and return an IObservable<bool> The canonical use case is to detect if a streaming server is still sending data.

I've come up with the following solution for it, but feel it's not the most clear as to how it works.

public static IObservable<bool> IsAlive<T>(this IObservable<T> source, 
                                           TimeSpan timeout, 
                                           IScheduler sched)
{
    return source.Window(timeout, sched)
                 .Select(wind => wind.Any())
                 .SelectMany(a => a)
                 .DistinctUntilChanged();
}

Does anyone have a better approach?

FYI -
Here are the unit tests and existing approaches that I've tried: https://gist.github.com/997003

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

梦里南柯 2024-11-17 09:48:41

这应该可行:

public static IObservable<bool> IsAlive<T>(this IObservable<T> source, 
                                           TimeSpan timeout, 
                                           IScheduler sched)
{
    return source.Buffer(timeout, 1, sched)
                 .Select(l => l.Any())
                 .DistinctUntilChanged();
}

这种方法也具有语义意义。每次有一个项目进入时,它都会填充缓冲区,然后传递 true。每次超时,都会创建一个空缓冲区并传递 false。

编辑:

这就是为什么 buffer-1 方法比窗口更好的原因:

var sched = new TestScheduler();
var subj = new Subject<Unit>();

var timeout = TimeSpan.FromTicks(10);

subj
    .Buffer(timeout, 1, sched)
    .Select(Enumerable.Any)
    .Subscribe(x => Console.WriteLine("Buffer(timeout, 1): " + x));

subj
    .Window(timeout, sched)
    .Select(wind => wind.Any())
    .SelectMany(a => a)
    .Subscribe(x => Console.WriteLine("Window(timeout): "+x));

sched.AdvanceTo(5);
subj.OnNext(Unit.Default);
sched.AdvanceTo(16);

产量:

Buffer(timeout, 1): True
Window(timeout): True
Buffer(timeout, 1): False

具体来说,窗口在整个超时时间内打开,并且不会在项目进入后立即关闭和重置这就是缓冲区限制 1 发挥作用的地方。一旦有项目进入,缓冲区及其计时器就会重新启动。

我可以将缓冲区重新实现为窗口,因为缓冲区的实现一个窗口,但是a)我认为缓冲区具有更好的语义意义,b)我不必选择很多。 Scott 的 Select 和 SelectMany 可以组合成一个 SelectMany(x => x.Any()),但我可以避免整个 lambda 并指定 Enumerable.Any 方法组,无论如何,这都会更快地绑定(微不足道)。

This should work:

public static IObservable<bool> IsAlive<T>(this IObservable<T> source, 
                                           TimeSpan timeout, 
                                           IScheduler sched)
{
    return source.Buffer(timeout, 1, sched)
                 .Select(l => l.Any())
                 .DistinctUntilChanged();
}

This approach makes semantic sense, too. Every time an item comes in, it fills the buffer and then true is passed along. And every timeout, an empty buffer will be created and false will be passed along.

Edit:

This is why the buffer-1 approach is better than windowing:

var sched = new TestScheduler();
var subj = new Subject<Unit>();

var timeout = TimeSpan.FromTicks(10);

subj
    .Buffer(timeout, 1, sched)
    .Select(Enumerable.Any)
    .Subscribe(x => Console.WriteLine("Buffer(timeout, 1): " + x));

subj
    .Window(timeout, sched)
    .Select(wind => wind.Any())
    .SelectMany(a => a)
    .Subscribe(x => Console.WriteLine("Window(timeout): "+x));

sched.AdvanceTo(5);
subj.OnNext(Unit.Default);
sched.AdvanceTo(16);

yields:

Buffer(timeout, 1): True
Window(timeout): True
Buffer(timeout, 1): False

To be specific, the window is open for the whole timeout and doesn't close and reset as soon as an item comes in. This is where the buffer limit of 1 comes into play. As soon as an item comes in, the buffer and its timer get restarted.

I could re-implement my buffer as a window, as buffer's implementation is a window, but a) I think buffer makes better semantic sense and b) I don't have to SelectMany. Scott's Select and SelectMany could be combined into a single SelectMany(x => x.Any()), but I can avoid the entire lambda and specify the Enumerable.Any method group, which will bind faster (trivial) anyway.

诗酒趁年少 2024-11-17 09:48:41

怎么样:

source.Select(_ => true)
    .Timeout(timeout, sched)
    .DistinctUntilChanged()
    .Catch<bool, TimeoutException>)(ex => Observable.Return(false));

How about:

source.Select(_ => true)
    .Timeout(timeout, sched)
    .DistinctUntilChanged()
    .Catch<bool, TimeoutException>)(ex => Observable.Return(false));
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文