您如何使用 .Net 2.0 通知客户端服务器上数据的更改？
想象一个 WinForms 客户端应用程序，它显示通过 HTTPChannel 使用 .Net Remoting 从服务器应用程序获取的相当复杂的计算数据。
由于客户端应用程序可能会运行整个工作日，因此我需要一种方法来通知客户端有新数据可用，以便用户能够在需要时开始重新加载数据。
目前，我正在使用远程 .Net 事件，将事件序列化到客户端，然后在客户端重新抛出该事件。
我对这个设置不太满意并计划重新实现它。
对我来说重要的是：
- 基于 .Net 2.0 的技术
- 易于使用
- 复杂性低
- 足够强大，可以在服务器或客户端重新启动后仍然正常工作
当仅限于 .Net 2.0 时，您将如何实现这样的功能？ 您会使用哪些技术/库？
我正在寻找如何解决这个问题的灵感。
编辑：
客户端和服务器存在于同一组织中，通常是 LAN，也可能是 WAN/VPN 情况。
该机制应该只让客户端知道有新数据可用。 我想继续远程处理以将实际数据发送给客户端，因为这工作得很好。 MSMQ 是 Windows 自带的，不是吗？ 所以使用它应该没问题，但我愿意接受任何替代方案。
Imagine a WinForms client app that displays fairly complex calculated data fetched from a server app with .Net Remoting over a HTTPChannel.
Since the client app might be running for a whole workday, I need a method to notify the client that new data is available so the user is able to start a reload of the data when he needs to.
Currently I am using remoted .Net events, serializing the event to the client and then rethrowing the event on the side of the client.
I am not very happy with this setup and plan to reimplement it.
Important for me is:
- .Net 2.0 based technology
- easy of use
- low complexity
- robust enough to survive a server or client restart still functional
When limited to .Net 2.0, how would you implement such a feature? What technologies / libraries would you use?
I am looking for inspiration on how to attack the problem.
Edit:
The client and server exist in the same organisation, typically a LAN, perhaps a WAN/VPN situation.
This mechanism should only make the client aware that there is new data available. I'd like to keep remoting for getting the actual data to the client since that is working pretty well. MSMQ comes with windows, doesn't it? So it should be ok to use it, but I'm open to any alternative.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我已经使用 MSMQ 实现了类似的通知机制。 客户端计算机打开一个本地公共队列，然后将其队列名称告知服务器。 当发生更改时，服务器会将通知推送到它知道的所有客户端队列中。 这样，客户端就会知道数据已准备好，即使在发送通知时数据尚未运行。
唯一的缺点是它需要客户端上的 MSMQ，因此如果您对客户端的计算机没有这种控制权，这可能不起作用。
为了获得额外的冗余级别（例如，如果客户端计算机完全关闭，因此客户端队列不可用），您可以在将通知传播到客户端之前在服务器上排队。 仅当成功联系客户端时（或者可能在 3 次失败尝试后等），服务器队列中的通知才会被删除。
同样在这方面，如果服务器在一段测量时间内未能将消息传递到客户端一定次数过了一段时间后，就会通知支持实体，发出错误警报，并将客户端队列从目的地列表中删除。 当我说“测量”时，我指的是对设置有意义的频率/持续时间。 就我而言，重试了 5 次，两次尝试之间的间隔为 5 分钟。
让客户端定期“更新”其通知订阅也可能是有意义的。 如果没有发生更新，则最终客户端队列会被服务中的“groomer”进程从目标列表中删除。
I've implemented a similar notification mechanism using MSMQ. The client machine opens a local, public queue, and then advises the server of it's queue name. When changes occur, the server pushes notifications into all the client queues that it's be made aware of. This way the client will know that data is ready, even if it wasn't running when the notification was sent.
The only downside is that it requires MSMQ on the clients, so this may not work if you don't have that kind of control over your client's machines.
For an extra level of redundancy (for example, if a client machine is completely down, and therefore the client queue is unavailable) you could queue notifications on the server prior to dissemination to clients. Notifications in the server queues are only removed when the client is successfully contacted (or perhaps after 3 failed attempts, etc.)
Also in that regard, if the server fails to deliver messages to a client a measured number of times, over a measured period of time, then support entities are notified, error alerts go out, and the client queue is removed from the list of destinations. When I say "measured" I mean a frequency/duration that makes sense to the setting. In my case, it was 5 retries with 5 minute intervals between attempts.
It might also make sense to have the client "renew" it's notification subscription at intervals. If a renewal doesn't occur, then eventually the client queue is removed from the destination list by a "groomer" process in the service.
听起来好像您需要实现基于消息队列的解决方案。 易于实施，可以重新启动，并且该技术在服务器（MSMQ、MGQSeries）和客户端（System.Messaging）上都很成熟
It sounds as though you need to implement a message-queue based solution. Easy to implement, can survive reboots, and the technology is mature both on the server (MSMQ, MGQSeries) and on the client (System.Messaging)
如果您找不到任何内置内容，并且假设您知道所有客户端的地址，则可以在数据更改时向它们发送 UDP 消息。 使用 UdpClient，这非常容易。 如果客户端应用程序可以假设某个端口上的任何 UDP 数据意味着它需要从服务器获取新数据，则数据报甚至不需要包含任何数据。
如果有必要，您甚至可以将其设为广播数据包（如果您不知道客户端是谁并且它们与服务器位于同一子网中），只要服务器不太“喋喋不休”即可。
无论您决定采用哪种解决方案，我都建议您避免让客户进行民意调查。 这将产生大量不必要的网络流量，并且仍然无法很好地执行。
If you can't find anything built-in and assuming you know the address of all the clients, you could send them a UDP message when data changes. Using UdpClient, this is very easy. The datagram doesn't even need to contain any data if the client app can assume that any UDP data on a certain port means it needs to get new data from the server.
If necessary, you can even make this a broadcast packet (if you don't know who the clients are and they are on the same subnet as the server), so long as the server isn't too "chatty".
Whatever solution you decide on, I would urge you to avoid having the clients poll. This will create a lot of unecessary network traffic and still won't perform all that well.
我通常会在客户端上使用 UI 计时器来定期访问服务器以查看是否有新的或更新的数据。 （假设您有一种机制来识别您有新数据，例如新行的时间戳、文件时间戳或包含最后计算日期的表等）
这样服务器就不必了解客户端。 客户可以在闲暇时查看等。
I would usually use a UI timer on the client to periodically hit the server to see if there was new or updated data. (Assuming you have a mechanism to identify that you have new data like time stamps for new rows, or file time stamps, or a table with last-calculated dates, etc)
That way the server doesn't have to know about the clients. The clients can check at their leisure, etc.