Websockets - 自定义排队系统有意义吗? [英] Websockets - does a custom queueing system make sense?
问题描述
我正在为回合制 Unity 游戏编写 node.js websocket 后端.这是我第一次使用 node.js 和 websockets，所以我想我会这样做，以便玩家可以重新连接，并会收到他们错过的任何消息.
然后我开始在游戏中实现它，并想测试我的排队系统，所以我关闭了我的互联网连接并重新打开 - 并惊讶地发现连接幸免于难，并且发送了任何错过的消息通过相同的连接.无需重新连接并将积压发送到新连接.
所以看起来 websocket 技术已经可以处理离线队列了?通过自己执行此操作(并通过将消息保留在服务器中增加服务器的内存负载)来使服务器代码复杂化是否有意义?
此外，如何在没有互联网连接的情况下保持套接字连接有效?是否有一个标准化的超时时间，或者除非我手动关闭它，否则双方都会跟踪它?
谢谢！
然后我开始在游戏中实现它，并想测试我的排队系统，所以我关闭了我的互联网连接并重新打开 - 并惊讶地发现连接幸免于难，并且发送了任何错过的消息通过相同的连接.无需重新连接并将积压发送到新连接.
关闭连接不会自动终止通过该连接建立的任何套接字.当套接字尝试发送数据失败时，套接字最终将关闭，并且经过多次重试和时间流逝后，它们得到的只是错误.如果套接字没有主动尝试发送任何数据，并且没有配置任何可以自动发送的保持活动状态，那么它可能会在连接失效的情况下在那里停留数小时，而根本不知道连接已失效.只要套接字未被使用，就没有自动方式它甚至知道它的端到端连接不再起作用.只有当它尝试使用连接并收到错误时，它才会弄清楚.
请注意，如果服务器进程崩溃，但连接保持活动状态，情况会有所不同.在这种情况下，服务器上的 TCP 堆栈会看到服务器进程崩溃，并会尝试清理它正在使用的任何套接字，并将关闭的数据包发送到另一端，另一端将被主动告知该套接字是关闭.但是，您只是中断传输的情况并不相同.
<块引用>所以看起来 websocket 技术已经可以处理离线队列了?通过自己执行此操作(并通过将消息保留在服务器中增加服务器的内存负载)来使服务器代码复杂化是否有意义?
websocket 是一个位于 TCP 套接字之上的协议层.TCP 是一种可靠的传输方式，这意味着当它在发送数据时遇到问题(但没有收到任何类型的套接字已被另一端关闭的通知)时，它会挂起该数据并重试.它最终会放弃并返回一些错误.
您可能对 socket.io 感兴趣，它是 webSocket 之上的一层.它添加了一些与此处相关的内容:
- 定期进行端到端的 ping，以便知道传输何时中断.
- 当套接字关闭或传输中断时无缝自动重新连接.
- 在连接暂时中断时自动对发送的数据进行排队.
<块引用>
此外，如何在没有互联网连接的情况下保持套接字连接有效?是否有一个标准化的超时时间，或者除非我手动关闭它，否则双方都会跟踪它?
正如我之前所说，如果两端都没有尝试发送数据，并且 Internet 连接在两个端点之间的某个地方中断，那么 webSocket 可能根本不知道该连接当前无法正常工作.定期了解连接是否正常工作的唯一方法是通过连接发送数据并查看是否得到及时响应.这就是 socket.io 对其 ping/pong 消息所做的.
无论物理连接发生什么，保持逻辑连接活动的方法是在物理连接之上使用一个额外的层(就像 socket.io 在 webSocket 之上所做的那样).然后，这允许您拥有可以在不更改逻辑连接的情况下重新启动物理连接的代码.这正是 socket.io 从客户端所做的.如果您想从服务器端获得类似的东西，您可能需要实现自己的数据队列，这些数据要发送给客户端，并且只有在确定它们已成功发送时才从队列中删除它们.
I'm writing a node.js websocket back-end for a turn-based Unity game. This is my first time using node.js and websockets, so I figured I'd make it so that a player can reconnect, and will get any messages they missed.
Then I started implementing it in the game, and wanted to test my queueing system, so I turned off my internet connection and turned it back on - and was surprised to find that the connection survived this, and any missed messages were sent through the same connection. No need to reconnect and send the backlog to the new connection.
So it seems like the websocket technology already handles offline queueing? Does it even make sense to complicate the server code by doing this myself (and adding to the memory load of the server by keeping the messages in there)?
Also, how can it keep a socket connection alive without internet connection? Is there a standardized timeout for it, or will both parties keep track of it unless I close it manually?
Thanks!
Then I started implementing it in the game, and wanted to test my queueing system, so I turned off my internet connection and turned it back on - and was surprised to find that the connection survived this, and any missed messages were sent through the same connection. No need to reconnect and send the backlog to the new connection.
Turning off a connection does not automatically kill any sockets that were established over that connection. sockets will eventually get closed when they unsuccessfully try to send data and, after a number of retries and time passage, all they get is errors. If a socket is not actively trying to send any data and does not have any sort of keep-alive configured that might do that automatically, then it may sit there for hours with a dead connection and simply not know the connection is dead. As long as the socket is not being used, there's no automatic way it even knows that it's end-to-end connection is no longer functioning. It is only when it tries to use the connection and gets an error that it would figure that out.
Note, things would be different if the server process crashed, but the connection stayed alive. In that case, the TCP stack on the server would see that the server process crashes and would attempt to clean up any sockets that it was using and would send close packets to the other end and the other end would be proactively told that the socket was closed. But, your case of just disrupting the transport does not do the same.
So it seems like the websocket technology already handles offline queueing? Does it even make sense to complicate the server code by doing this myself (and adding to the memory load of the server by keeping the messages in there)?
A websocket is a protocol layer on top of a TCP socket. TCP is meant to be a reliable transport which means that when it has trouble sending data (but has not received any sort of notification that the socket has been closed by the other end), it hangs on to that data and retries. It will eventually give up and communicate back some error.
You may be interested in socket.io which is a layer on top of webSocket. It adds a couple things that are relevant here:
- Regular ping from end-to-end so it will know when the transport has been interrupted.
- Seamless auto-reconnect when the socket is closed or the transport is interrupted.
- Automatic queuing of data sent while the connection is temporarily interrupted.
Also, how can it keep a socket connection alive without internet connection? Is there a standardized timeout for it, or will both parties keep track of it unless I close it manually?
As I said earlier, if neither end is attempting to send data and the internet connection is interrupted somewhere in the middle between the two endpoints, then the webSocket may simply not know that the connection is currently not functional. The only way to regularly know whether the connection is functional is to send data across the connection and see if you get a timely response. This is what socket.io does with its ping/pong messages.
The way to keep a logical connection alive no matter what happens to the physical connection is to use an extra layer on top of the physical connection (like socket.io does on top of webSocket). This then allows you to have code that might restart the physical connection without changing your logical connection. This is exactly what socket.io does from the client side of things. If you wanted something similar from the server-side of things, you would probably need to implement your own queue of data that you want to send to a client and only remove things from the queue when you are sure they have been successfully sent.
这篇关于Websockets - 自定义排队系统有意义吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
