perl – 非事件驱动的HTTP服务器环境中的服务器端Websocket实现

发布时间：2020-12-15 23:32:47 所属栏目：大数据来源：网络整理

导读：我试图理解服务器端Websocket端点的实现/选项 – 特别是在使用PSGI / Plack的Perl中我有一个问题：为什么所有服务器端websocket实现都基于事件驱动的PSGI服务器(Twiggy,Tatsumaki等). )？我认为websocket通信是异步的,但非事件驱动的PSGI服务器(比如Starman

我试图理解服务器端Websocket端点的实现/选项 – 特别是在使用PSGI / Plack的Perl中我有一个问题：为什么所有服务器端websocket实现都基于事件驱动的PSGI服务器(Twiggy,Tatsumaki等). )？

我认为websocket通信是异步的,但非事件驱动的PSGI服务器(比如Starman)可以产生一个异步监听器来处理websocket方面的事情.我已经看过(但不了解)Websocket服务器的PHP实现,为什么不用PSGI就可以完成同样的操作而不必将服务器更改为事件驱动的服务器？

解决方法

处理套接字的基础网络逻辑取决于平台,操作系统和特定的软件实现.
最常见的三种方法是：

> pull – 阻塞常量“询问”socket是否有一些数据.这种方法很糟糕,因为只要等待一些数据,它就会阻止主线程的执行.
>每个套接字的线程 – 每个新连接都涉及创建新线程并在该线程内以阻塞方式询问每个套接字.所以它不会用逻辑阻塞主线程.这种方法很糟糕,因为为每个连接创建线程对于内存而言过于昂贵,并且可能基于操作系统和其他标准大约1Mb或RAM.
> async – 使用系统功能在有问题时“通知”您的进程.因此,您可以在应用程序准备就绪后做出反应(如果是单线程应用程序),或者甚至可以直接在单独的线程中做出反应这种方法效率很高,因为它可以节省RAM,并且允许您的应用无需等待或询问数据即可工作.它利用大多数操作系统和平台提供的现有功能.

考虑到这一点,您确实可以创建单进程功能方式来处理套接字流量.但事实证明,这根本没有效率.这就是为什么完全异步模型在今天是主要的,因为大多数语言和平台确实支持这种范例.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!