请稍等一下,我只是想确保我没听错。您还没有写出确切的问题,所以我假设您在某些基础上被困在某个地方。我也会忽略 NancyFX,我不知道,我假设如果它支持这种情况,你会在文档中找到它。
要让客户知道某些事情发生了变化,您基本上只有 3 个选项:
(a) 服务器上有一个旧事件列表,服务器会在事件发生时更新它,客户端会定期读取它们并调用执行 Ping 的“通知”!
(b) 每个客户端打开到服务器的连接并保持打开状态,服务器记住连接,当新的连接发生时,通过已经打开的连接向所有客户端发送消息,客户端获取消息并调用他们的“通知”平吗!
(c) 客户端向服务器发送注册消息,它包含回调地址/端口/等,服务器存储。当事件发生时,服务器读取列表并将信息发送到这些地址,客户端处理这些请求并根据请求调用它们的通知
由于您使用“发布-订阅”一词,我假设您的意思是 (C)。
对于这个选项,关于通知,客户端/服务器的角色实际上是颠倒的。在正常情况下,服务器向客户端公开 API,客户端连接到它,发送请求,服务器处理它并返回一些响应。在这里,双方必须做同样的事情。客户端应用程序还必须向服务器公开一个可调用的 API,以便当“事件”发生时,服务器可以连接到客户端的 API 并向他发送带有通知数据的请求。
现在,您将如何构建 API - 由您决定。你可以有一个Notify(string xmlizedOrJsonizedData)方法,你可以有参数Notify(string infotype, datetime, data),也可以有很多方法NotifyEmal(...) NotifyBullet(...) ...——在实现注册和订阅记账之后,你只需要服务器调用正确的请求数据到客户端的api,只需就像客户一直在做同样的事情。
现在编写所有这些内容并重新发明轮子是一项艰巨的工作。有很多图书馆已经可以做到这一点。我看了看,在 NancyFx 文档中没有找到任何关于此的内容。也许您可以使用它来创建客户端 api,就像您创建服务器端 api 一样,但是.. 有一个问题。
客户端和服务器端不同。
当客户端与服务器对话时,只有一个服务器可以发送和收听。你可以用幼稚的方式来做,如果你愿意,甚至可以阻止 UI。当服务器发回通知时,可能有 10000 个客户端。您甚至不应该以幼稚的方式开始编写它。循环这么多客户端并等待完成可能会完全冻结您的服务器,如果不冻结,则会导致减速和超时。此外,服务器是公开的。客户不是。客户端通常位于 NAT、防火墙和所有其他有趣的事物后面,这些事物将流量从客户端 -> 传递到 -> 服务器,但可能会阻止另一个方向的流量。最基本的例子是阻塞端口。服务器上的:80 几乎总是通过防火墙,但客户端上的:80 可能不可用,并且当客户端在:23122 上打开它的api 时,它可能不会在他们的防火墙/路由器上配置.. 除非你处理与 upnp/etc.
这就是为什么选择一个可以为您完成所有这些工作的库是件好事。抱歉,我现在想不起任何名称,请查看 google 的 PublishSubscribe 模式、客户端通知或推送通知服务器端图书馆。
这就是为什么发明了一种叫做“WebSockets”的东西。这本质上是我在开始时谈到的选项(B)。真的很值得研究。订阅-发布的整个概念也可以通过 websocket 调用/响应服务器/客户端 API/接口来实现,但它可以为您节省大量工作和网络问题。
我发现了一个可以use Nancy and SignalR 的信息,所以这可能是一个很好的开始。