【问题标题】:Instant Challenge/Notifications system即时挑战/通知系统
【发布时间】:2011-07-22 17:04:19
【问题描述】:

我的设置:目前使用 Apache、PHP、MYSQL 运行专用服务器。 我的数据库已全部设置并正确存储所有内容。我只是想弄清楚如何以有效的方式最好地展示事物。

对于基于网络的游戏来说,这将是一个具有挑战性的实时系统。

  • 用户 A 向用户 B 发送质询

  • 用户 B 会立即收到警报,并且必须对是否 接受或拒绝

  • 一旦用户 B 接受,他和用户 A 都会被带到特定页面 由数据库提供(这没有什么特别的事情发生 页面,它们不需要同步或任何东西)

用户 B 的响应是简单的是或否,用户 B 没有设置其他参数,用户 A 发送挑战时已经定义了他们要去的页面。

无论我为此挑战系统实施何种配置,我都假设它也适用于即时全站通知。唯一的区别是通知不需要用户 B 的即时响应。

我已经阅读了长轮询技术、彗星等。但我仍在寻找实现这一目标并使其可扩展的最佳方法的意见。

我愿意尝试任何东西,只要它能与我当前的 PHP 和 MYSQL 设置一起使用(或串联)。谢谢!

【问题讨论】:

  • 感谢您对不同方法的澄清。你介意说说优缺点吗?
  • 当然。不过,我会将其移至答案。

标签: php ajax long-polling


【解决方案1】:

您正在询问从服务器到客户端的通知。这可以通过让客户端频繁轮询更改或让服务器保持对客户端的开放访问并推送更改来实现。两者各有优缺点。

编辑:更多信息

  • 拉法优点:
    • 易于实施
    • 服务器对于谁在获取数据可能非常幼稚
  • 拉法缺点:
    • 客户端的资源密集型,与轮询频率无关
    • 时间与资源的崩溃:更频繁的轮询意味着更多的资源利用率。更少的资源利用率意味着更少的即时数据。
  • 推送方法优点:
    • 服务器拥有更多的整体控制权
    • 数据立即发送到客户端
  • 推送方法缺点:
    • 服务器端可能非常占用资源
    • 您需要实现某种方式让服务器知道如何访问每个单独的客户端(例如,Apple 使用设备 UUID 作为其APNS

维基百科要说的(实际上是一些非常好的东西):PullPush。如果您倾向于 Push 模型,您可能需要考虑将您的应用设置为 Pushlet

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-12-19
    • 2021-01-07
    • 1970-01-01
    • 1970-01-01
    • 2014-08-04
    • 2015-12-19
    • 2021-02-13
    • 1970-01-01
    相关资源
    最近更新 更多