ASP.NET中是否存在共享会话的概念？

Question

我正在开发一个基于ASP.NET的Web应用程序，它将包含一个单页面，该页面上将有一个类似于大富翁的游戏板。 我正在尝试确定最佳的架构方法。 我已经确定了以下主要要求：

- 最多六个用户共享一个游戏状态对象。 - 用户需要（相对）及时了解游戏的当前状态，例如轮到谁了，当前用户刚刚投了什么骰子，每个其他用户有多少钱等。

我考虑过将游戏状态保存在数据库中，但是如果可以保持更新缓存中的游戏状态对象，那么在数据库中一遍遍更新似乎有些过度。例如，流程可能如下所示：

- 接收用户数据请求。 - 在数据库中查找数据。从数据创建对象。 - 根据游戏状态验证用户是否有执行请求的权限（例如确保现在轮到他们或者有足够的钱来购买那个物业）。 - 更新游戏对象。 - 将游戏对象写回数据库。 - 对每一个请求重复以上步骤。

请注意，单台服务器将为几个并发游戏提供服务。

我考虑使用AJAX向ASP.NET页面进行请求，也考虑使用Silverlight向Web服务进行AJAX请求，还考虑使用Silverlight中的WCF双工通道。

我无法确定最佳方法。所有方法似乎都有其缺点。对于这种情况，有没有人有经验并愿意分享这些经验？如果我描述得不够清楚，请随时提出您自己的问题！谢谢。

更新：是否有人对基于我上面提到的三个选项之一实现与服务器连接有建议？

- David

Answer 1

您可以使用ASP.Net Cache或Application state来存储游戏对象，因为它们在用户之间是共享的。 由于可以从缓存中删除对象以节省内存，因此缓存可能是最好的位置。

如果您使用唯一键将游戏对象存储在高速缓存中，然后将该键存储在每个访问者的会话中，并使用它来检索共享的游戏对象。 如果缓存已被清除，则将从数据库重新创建对象。

- Rune

---

应用程序状态是仅适用于ASP.NET页面还是Web服务也适用？ - David

如果Web服务托管在Asp.Net中，则会执行此操作。如果它是托管在服务或应用程序中，则我不确定... - Rune Grimstad

Answer 2

虽然更新数据库似乎有些过度，但在扩展时具有优势，因为您可以让多个Web头与一个后端进行通信。

更大的问题是如何向客户端传递游戏状态。尽管定期完全更新游戏状态可确保捕获任何更改并使所有客户端保持同步，但游戏状态通常相当大。

还要考虑到通常希望游戏状态消息触发动画或其他显示更新以描绘动作（例如，如果一块棋子移动，大多数情况下不应该只出现在目标位置...它应该沿着棋盘移动）。

因此，结合两者最好的解决方案之一是保留一个数据库，其中收集了表格中执行的所有操作，并具有连续的ID。当客户端请求更新时，它可以提供上次知道的所有操作之后的所有操作，并且客户端可以“执行”这些移动。这意味着即使请求失败，它也可以简单地重试请求，并且不会丢失任何操作。

服务器还可以从相同的数据中维护游戏状态的内部视图。它还可以拒绝非法操作并防止它们进入游戏操作表（从而防止其他客户端被错误更新）。

最后，由于服务器拥有“真正的”游戏状态，因此客户端可以定期与之进行检查（这将允许您找到客户端或服务器代码中的错误）。由于应将服务器数据库视为主要数据库，因此可以重新传输整个游戏状态以纠正任何不正确的状态，这样即使出现小的客户端错误，也不会破坏体验（除了可能需要暂停，等待状态下载完成）。

- Godeke

---

您描述的是每个用户拥有自己独立的客户端状态。对于此类游戏，更容易实现为单一（共享）状态和逻辑机器，由四名玩家同时查看。 - vmarquez

服务器端只有一个状态，它强制执行规则，但队列中的动作可以让系统即使有一个玩家遇到大量延迟时也能顺畅运行。单个共享状态的想法听起来很好，但如果一个玩家的延迟导致所有人都降至最低公分母，那么这个想法就变得不太可取了。 - Godeke

我同意，我之前考虑过实现一个历史记录，你告诉服务器你收到的最后一条消息，然后服务器会给你自那时以来的所有消息。 - David

Answer 3

为什么不创建一个应用程序级对象来存储您的详细信息呢？请参阅ASP.NET中的应用程序状态和全局变量以获取详细信息。您可以使用sessionID作为每个玩家数据的键。

您还可以使用Cache来执行相同的操作，使用长时间超时。这样做的优点是，在一段时间（例如6小时）之后，旧数据可以从Cache中清除。

- Leo Moore