Google Cloud上的实时游戏:渠道API还是计算引擎？

Question

我们需要开发一款具有实时性能的多人游戏.这需要在全球范围内运行(美国,欧洲,亚洲的服务器),并支持巨大的流量.使用Google Cloud服务进行托管.

我们正在考虑使用Jam with Chrome,Chrome Maze或Cube Slam等参考文献.

游戏 :

• 2名球员挑战比赛
• 我们需要同时显示2名球员的进展
• 每场比赛可持续约30至45秒

托管:

我们显然会在AppEngine上主持网站,自动扩展,但正在考虑为实时服务器提供2种解决方案:

1. 使用带有计算引擎的websocket服务器
   
   就像他们为Jam with Chrome,Maze等所做的那样.
   开发我们自己的websocket服务器(技术TBD),部署在欧洲,美国,亚洲的数据中心,处理扩展,在它们之间同步,计算服务器上的延迟问题和客户端等,
   但它是非常技术上的挑战,因为我们的时间很短,和失踪管理员SYS和网络家伙现在.

2. 或使用Channel API
   
   我们知道它不是websocket平台,实时性能较低.
   但对我们和我们拥有的时间来说,这将更加简单和安全.
   所以,我们也希望了解更多相关信息.

在任何情况下,我们认为我们可以在前端使用一些图形技巧,使其看起来像实时,但它确实取决于我们有100~500ms或500ms~10s的延迟.

一些问题 :

• 对于不同的解决方案,延迟范围值会是什么样的？
  (带有GCE的Chrome与Chrome有100ms的距离,Channel API可以达到几秒钟吗？)
• Channel API服务器如何处理高流量,缩放如何工作,延迟是否会非常高？(没有关于频道文档的信息？)
• 如果法国有人在美国与某人玩,连接到不同的服务器,等待他们同步,如何处理它会怎么样？
• 有什么建议或经验可以分享吗？
• 有趣的阅​​读或观看？(看到一些但不是很精确)
• 还有其他方法吗？

感谢您的任何帮助评论!

编辑:

• 只有2名球员连接在一起,可能来自不同的世界区域,不需要广播.
• 我们可以找到一些前端技巧来避免服务器端处理.这是两个玩家之间的比赛,所以我们实际上只需要比较他们的进展,真正的赢家分辨率并不重要,因为没有真正的东西可以获胜,这更有趣.

Answer 1

如果您需要服务器来处理数据:

我肯定会在Compute Engine上使用websockets!

Channels API要慢得多,而且非常不可预测(延迟因消息而异)!数据必须转到Channels服务器,后者将其发送到App Engine实例,后者必须向Channels服务器发送请求,该服务器将消息推送到客户端.如果你想要减少潜伏期,那里有太多的事情发生了!

这是一个Channels API压力测试:
http:
//channelapistresstest.appspot.com/尝试点击"发送5"按钮很多,你会看到延迟数字达到几秒钟.

Channels API在高负载下也非常昂贵(它可能无法很好地扩展,即使Google当然可以通过更多实例来解决这个问题).

在保持延迟时,地理定位非常重要.使用Compute Engine上的websocket服务器,您可以将您的欧洲访问者发送到Google的欧洲数据中心,将美国访问者发送到美国数据中心(使用AppEngine将提供的地理位置标头).您对Channels API(或应用引擎,您的所有消息都通过其中继)没有此类控制权.也许谷歌有渠道API的边缘服务器(我不知道),但如果你的AppEngine实例位于地球的另一边,那也没关系.

如果您不需要服务器来处理数据:

您应该与WebRTC建立点对点连接,直接在用户的浏览器之间发送内容.那是Cube Slam的确如此.(WebRTC需要一些初始握手("信令"),因此两个对等体可以找到彼此,并且Channels API可以很好地进行握手,这只是用于建立对等连接的几条消息.)

WebRTC DataChannels API将为您提供类似于websocket的界面,channel.onmessage = function(e) { yadayada()... };并channel.send("yadayada");在同级之间发送您的数据.

有时,WebRTC无法建立点对点连接.然后它将回退到TURN服务器,该服务器在对等体之间中继流量.Cube Slam使用在ComputeEngine上运行的TURN服务器(在欧洲和美国都保持延迟),但这只是真正的点对点无法实现的后备.