英文:
Is the mux in this golang socket.io example necessary?
问题
在我正在制作的应用程序中，用户始终是游戏的一部分。我想设置一个socket.io服务器，与游戏中的用户进行通信。我计划使用http://godoc.org/github.com/madari/go-socket.io中定义的newSocketIO函数来创建一个新的socketio实例。
我想，可以创建一个将游戏ID映射到socket.io实例的映射表，并对它们进行配置，使它们侦听表示游戏ID的URL。
这样，我就可以使用广播和广播排除等方法，向单个游戏中的所有玩家广播。然而，我需要为每个游戏启动一个新的goroutine，并且我不了解它们的性能特征，不知道这是否可扩展，因为单个socketio实例的请求速率将非常低，在高峰时段大约为1次/秒，但在其他时间连接可能会空闲数十秒钟（除了心跳和可能由socket.io协议指定的其他通信）。
我是否最好创建一个socket.io实例，并跟踪哪些连接属于哪些游戏？
英文:
In an app that I'm making, a user is always part of a 'game'. I'd like to set up a socket.io server to communicate with users in a game. I'm planning to use http://godoc.org/github.com/madari/go-socket.io go-socket.io, which defines the newSocketIOfunction to create a new socketio instance.
Instead of creating one socketio instance, I thought it might be possible to create a map that maps game id's to socket.io instances, and configure them so that they listen on an url that represents the game id.
This way, I can use methods such as broadcast and broadcastExcept to broadcast to all players ithin a single game. However, I'd have to start a new goroutine for every game, and I don't know enough about their performance characteristics to know if this is scalable, since the request rate for a single socketio instance will be very low, about 1/second at peak times, but the connection might be idle for tens of seconds at other times (except for heartbeat, and possibly other communication specified by the socket.io protocol).
Would I be better off creating 1 socket.io instance, and tracking which connections belong to which games?
答案1
得分: 3
我会为你翻译以下内容：
对于每个游戏，我都需要启动一个新的goroutine，但我对它们的性能特征了解不够，不知道这是否可扩展。
尽管如此，Go调度器被设计成能够高效地处理成千上万甚至百万个goroutine。
例如，Go标准库中的默认net/http服务器为每个客户端都会生成一个goroutine。
只要记得在goroutine完成工作后返回即可，否则你会积累很多闲置的goroutine。
如果我创建一个socket.io实例，并跟踪哪些连接属于哪些游戏，会更好吗？
我不参与这个项目，但如果它遵循Go的“做好事情”的理念，那么这应该没有关系。不过，你可以通过对这两种方法进行性能分析来找出哪种方法更好。
英文:
> I'd have to start a new goroutine for every game, and I don't know enough about their performance characteristics to know if this is scalable
Fire away, the Go scheduler is built to efficiently handle thousands and even millions of goroutines.
The default net/http server in the Go standard library spawns a goroutine for every client for instance.
Just remember to return from your goroutines once they're done working. Else you'll end up with a lot of stale ones.
> Would I be better off creating 1 socket.io instance, and tracking which connections belong to which games?
I'm not involved in the project but if it follows Go's "get sh*t done" philosophy, then it shouldn't matter. You can find out what works better by profiling both approaches though.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论