英文:
Is It Necessary to Add Ack Mechanism To Websocket Server?
问题
我们正在使用golang+gin+json+gorilla websocket构建一个websocket服务器，用于将服务器端的消息推送到浏览器。
我们计划为前端提供一些订阅命令，这意味着来自服务器端的消息将被发送给那些订阅了目标主题的用户。
我的困惑是我们是否需要在这里添加确认机制？例如，当客户端订阅一个主题时，服务器保存这个映射：用户 -> 主题。
服务器是否需要为每个订阅请求向客户端发送响应（就像我们对RPC请求所做的那样）？如何做到这一点？以下是我的疑问
type MsgHeader struct {
ReqId string `json: reqId`
Cmd string `json: cmd`
// "req"或"rsp"之一
// 是否有必要有这个字段???
Type string `json: type`
}
我的意思是应用层的确认，就像我们对RPC请求所做的那样。对于RPC请求，即使响应本身为空，我们也会发送响应，类似于：
type SubscriptionRsp struct {
Code int
Msg string
Data interface{}
}
英文:
We are building a websocket server via golang+gin+json+gorilla websocket to push messages from server side to browser.
We plan to provide frontend with some subscription command, which means messages from server side will be sent to those users who subscribed target topic.
My confusion is whether we need add Ack mechanism here? For example, when client subscribe one topic, the server saved this mapping: user --> topic.
Is it necessary for the server to send a response for each subscription request to clients (Like that we do for an RPC request)? And how to do that? Below is my consumption
type MsgHeader struct {
ReqId string `json: reqId`
Cmd string `json: cmd`
// either of "req" or "rsp"
// is it necessary to have this field???
Type string `json: type`
}
I mean the application level acknowledgement, like what we do for RPC requests. For RPC request, we send responses even when the response itself is empty, something like:
type SubscriptionRsp struct {
Code int
Msg string
Data interface{}
}
答案1
得分: 2
不，这并不是必需的。
Websocket规范（RFC 6455）并没有要求这样做。
在握手完成并且端点发送关闭帧之前，数据帧可以由客户端或服务器在任何时间传输。
在发送和接收数据部分中，并没有提到其他关于确认消息的内容。
因此，任何确认都完全是你的应用程序的实现细节。如果你开发了一个具有重试失败消息功能的弹性客户端，这可能会很有用。在这种情况下，“失败”可能指的是成功发送到服务器但未按预期处理的消息。
英文:
No, it's not necessary.
The Websocket specs (RFC 6455) does not mandate this.
> A data frame MAY be transmitted by either the client or the server at
any time after opening handshake completion and before that endpoint
has sent a Close frame
Nothing else about acknowledging messages is said in the Sending and Receiving Data section.
Therefore any ACK is entirely an implementation detail of your application. It may be useful if you develop a resilient client that retries failed messages, where "failed" could a message that is successfully sent to the server but not processed as expected.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论