使用websocket-sharp for .NET，服务器如何关闭WebSocketBehavior？

Question

我正在尝试在一个项目中使用websocket-sharp，服务器需要能够断开websocket连接。

这些连接由WebSocketBehavior类表示，您可以从中继承。WebSocketBehavior上没有Stop、Close或Disconnect方法。我找到的最接近的是：

WebSocketBehavior.Context.WebSocket.Close

所以我尝试在我的覆盖类中添加一个方法

public class MySocket : WebSocketBehavior
{
    public void Close()
    {
        base.Context.WebSocket.Close();
    }
}

但是当打开日志记录时，这会导致错误。

2/5/2016 7:08:25 PM|Error|WebSocket.Close|This operation isn't available in: closed

服务器如何断开/关闭WebSocket连接？

- gman

---

你从哪里调用了你示例中的Close()方法？实际上，对我来说它很好用。因此，您可能需要提供更多详细信息，以了解您如何获得错误。 - Evk

你的错误看起来像是你试图关闭一个已经关闭的连接（比如客户端在这个时候已经关闭了它）。 - Evk

出于好奇，您是否考虑过websocket-sharp的替代方案？如果是，为什么选择它？我个人使用的是http://vtortola.github.io/WebSocketListener/，但也许您知道其他有用的替代方案。 - Evk

@DarioOO，你似乎非常擅长理解糟糕的API以及如何遵循它们超级晦涩的高级方法。而我期望一个API是有意义的。当它没有意义时，高级方法就会变得模糊不清，因为既然它们没有意义，就没有办法猜测我应该在哪里寻找。我从来不会想到去Sessions对象上查找。事实上，我甚至从未想过在单个WebSocketBehavior中查找Sessions对象。如果我显得有些防御，请原谅，但我认为你假定我不知道如何寻找高级方法是很居高临下的。 - gman

是的，这就是为什么我提出了这个问题，因为A.B.C.D似乎是错误的，但由于API设计不良，没有明确的方法可以解决它。 - gman

Answer 1

如在他们的库的一个工单中所述：

您只需要关闭相关的会话即可：

 Sessions.CloseSession(ID);

编辑：

这段代码和原帖中的代码相同，但是通过正确的抽象化调用，理论上应该可以工作。然而，他试图从“低级别”访问一些内容，这让我怀疑他绕过了“公共方法”访问其他内部功能，可能会导致错误行为（例如由“公共方法”调用的内容不再起作用），建议您仅从适当的抽象层面访问所有内容，以避免问题。如果问题仍然存在，则应创建一个票证请求在原始存储库中修复错误。这样的错误无法在那里修复，因为需要了解您编写的所有其他代码。

之后，您应该使用日志文件跟踪客户端和服务器端，以发现发生了什么，例如Evk在评论中所述，客户端已关闭连接。

- CoffeDeveloper

---

这是正确的，而且这种方式将会调用作者在示例中提供的“完全相同”的代码。 - Evk

谢谢。我对正确的抽象并不确定。文档很简短，自述文件示例通过覆盖WebSocketBehavior的方法来与套接字通信。必须通过Sessions和ID进行操作似乎是一个完全错误的抽象。为什么单个套接字要关心会话和ID？它只想关闭自己。它不应该区分自己和其他会话。以File为例。它是File.Close而不是FileSystem.CloseFile(someFile.ID)。因此，正确的抽象this.Sessions.CloseSession(this.ID)一点也不清楚。 - gman

通过正确的抽象，我指的是尽可能使用最高级别的方法而不必访问内部属性。我并不是说库的设计方式与我设计的方式相同，或者存在一种好的使用方式，但是希望开发人员至少遵循一些良好的编程原则，您应该同意，在一般情况下，访问“成员内部成员”以调用方法是不好的，如果可能的话，应该使用更高级别的方法（封装和信息隐藏）。 - CoffeDeveloper

举个例子，对我来说这个库就是一团糟，因为它允许从行为上几乎可以访问所有内容，使用户能够进行他们想要的更改，并引发了一系列副作用，这些副作用远不能完全测试。当做“坏”事情时，开发人员至少应该留下一份文件/记录，解释为什么做了一些不好的事情，但通过这样做解决了其他哪些问题。（我不打算把所有东西都记录下来，但至少重要的决策应该这样做） - CoffeDeveloper

我同意你的观点，但糟糕的API设计导致这些抽象概念根本不清晰。如果我有一个“文件”对象，我不会期望在“文件”上找到一个名叫“OpenFiles”的属性，并将某个ID传递给它，尤其是当“文件”既不应该有“OpenFiles”属性也不应该有“ID”属性时。我的意思是，让我遵循正确的抽象并假设我应该期望这些抽象概念存在，这本身就是错误的。我无法得知“Sessions”是我应该关注的内容。 - gman