Owin Websockets - 了解IOwinContext和WebSocketAccept

Question

阅读here并查看示例here：

我试图了解WebSocketAccept实际上做了什么。我知道WebSocketAccept是：

using WebSocketAccept =
    Action
    <
        IDictionary<string, object>, // WebSocket Accept parameters
        Func // WebSocketFunc callback
        <
            IDictionary<string, object>, // WebSocket environment
            Task // Complete
        >
    >;

并以这种方式使用：

public void Configuration(IAppBuilder app)
    {
        app.Use(UpgradeToWebSockets);
        app.UseWelcomePage();
    }

    // Run once per request
    private Task UpgradeToWebSockets(IOwinContext context, Func<Task> next)
    {
        WebSocketAccept accept = context.Get<WebSocketAccept>("websocket.Accept");
        if (accept == null)
        {
            // Not a websocket request
            return next();
        }

        accept(null, WebSocketEcho);

        return Task.FromResult<object>(null);
    }

那么接受（）实际上是做什么的？它是否正在调用Func＆lt;＆gt; WebSocketAccept的属性和定义WebSocketEcho的方法？ WebSocketEcho定义为：

  private async Task WebSocketEcho(IDictionary<string, object> websocketContext)

那么websocketContext来自哪里？如果我们一旦确定它是一个Web套接字请求，我们想要在管道中进一步传递该怎么办？

Answer 1

什么是WebSocketAccept？

WebSocketAccept是using alias

示例：

...
using Foo.Bar
using MyBar = Fee.Bar
...

这里我们使用来自2个不同命名空间的Bar，但我们将第2个命名为＆＃39; MyBar＆＃39;所以我们可以区分这两者。

为什么使用别名作为WebSocketAccept？

这种情况下的别名只是一种方便，因此您不必输入整个内容，这意味着您可以使用别名而不是在编写整个名称时使用别名。

了解WebSocketAccept

如果我们仔细观察，我们会看到类型是：

Action<A, B>

这意味着它本质上是一个不返回的函数，并且在C＃lambda中有两个参数：

(A, B) => { }

我们看到第一个参数（A）是：IDictionary<string, object>，也称为Owin环境。

第二个参数是（B）是：Func<C, D>这意味着它是一个带C并返回D的函数。在C＃lambda中：

(C) => { return D; }

然后我们需要深入研究第二个参数（B）的第一个参数（C）。我们发现它需要一个Owin环境并返回Task。

什么是接受？

accept尝试从IOwinContext中提取参数并将其映射到WebSocketAccept类型。

如果它无法提取它们，则为null，我们将继续使用下一个中间件。

否则它是一个websocket请求，我们调用带有2个参数（WebSocketAccept）的函数，如上所述（Action<A, B>）。

第一个参数是普通字典，它包含websocket接受参数。

第二个参数是一个获取字典并返回任务的函数。

该函数由其他人调用，代码所做的是将回调函数传递给调用者。

然后调用者使用正确的参数调用该函数。因为调用者知道函数的签名。该函数在接受websocket连接请求后被调用。因此评论回调。

一旦我们确定它是一个Web套接字请求，我们想要将其进一步传递给管道？

在示例中，回调函数是WebSocketEcho，但基本上您可以传入满足以下函数签名的任何函数：

Task MyCallbackFunction(IDictionary<string, object> context)
{
    // Do something
    return Task.FromResult(0);
}

外卖是你没有调用该函数，为你调用该函数。您在协商Web套接字请求连接后指定，您可以决定发生了什么。

为每个客户端调用WebSocketEcho函数一次，并循环直到客户端选择关闭连接。与此同时，它回应它收到的任何东西。

免责声明：我也只是想绕过网络套接字并且自己，但我想分享我的发现为后代，因为没有人回答你的问题。我欢迎任何更正。

修改
我注意到我自己的实验，如果你从回调函数返回websocketContext连接将被Abort编辑。这意味着如果在结束回调后传递websocketContext，则无法在连接上发送/接收消息。

<强>更新
上次我尝试在Windows 2008 R2 IIS 7.5服务器上使用它时，我无法使websocket工作。然后根据这个：https://stackoverflow.com/a/14130152/1640121 - IIS 7.5服务器不支持websockets 这意味着，如果您的应用程序托管在IIS 7.5中，则无法使用websockets。

然后我想到了一个可能的解决方案：

1. 使用单独的应用程序，例如处理websocket请求的服务程序（在IIS之外）。
2. 使用反向代理将请求映射到服务应用程序

这对我来说太麻烦了，这让我暂时不再实施websocket ......