CN114827154A - 一种端口监听方法、系统及服务器 - Google Patents

Abstract

本发明公开了一种端口监听方法、系统及服务器，其中，应用于端口监听进程中的方法包括：在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中；接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听；在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。本申请提供的技术方案，能够适应频繁变更端口的应用场景。

Description

一种端口监听方法、系统及服务器

技术领域

本发明涉及互联网技术领域，特别涉及一种端口监听方法、系统及服务器。

背景技术

在CDN(Content Delivery Network，内容分发网络)中，通过代理服务器，可以为域名提供加速服务。

随着CDN中域名规模的不断增大，加速域名通常需要频繁地变更端口。而在现有的代理服务器中，需要监听的端口通常是提前配置好的，一旦出现端口变更，主进程(master进程)就需要重新进行配置初始化，并创建出新的工作进程(worker进程)提供服务，这样无疑会浪费较多的系统资源。

针对上述缺陷，目前提出了一些改进的方案。例如，一种方案可以将所有可能监听的端口都提前监听好，以备端口更新的时候使用。又例如，另一种方案可以通过端口映射的方式，将特殊端口映射为完成监听的端口。然而这样的改进方案通常也具备一定的缺陷。第一种方案需要监听大量的端口，系统资源也会造成极大的浪费，而且加速服务中可能出现的特殊端口无法提前监听。第二种方案通过端口映射时，无法复原出原始的端口，而加速域名提供需要对原始的端口进行差异化处理，这样无疑给加速服务提高了难度。

因此，目前亟需一种能够有效变更监听端口的方案。

发明内容

本申请的目的在于提供一种端口监听方法、系统及服务器，能够适应频繁变更端口的应用场景。

为实现上述目的，本申请一方面提供一种端口监听方法，所述方法应用于端口监听进程中，所述方法包括：在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中；接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听；在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。

为实现上述目的，本申请另一方面还提供一种端口监听系统，所述系统包括：初始化单元，用于在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中；判断单元，用于接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听；反馈单元，用于在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。

为实现上述目的，本申请另一方面还提供一种端口监听方法，所述方法应用于工作进程中，所述方法包括：遍历共享内存中的监听结构信息，并根据遍历结果确定待监听的端口标识；向端口监听进程发送包含所述端口标识的端口监听请求，并接收所述端口监听进程针对所述端口监听请求反馈的文件描述符；调用预设接收接口获取所述文件描述符处的请求，并处理获取的所述请求。

为实现上述目的，本申请另一方面还提供一种端口监听系统，所述系统包括：遍历单元，用于遍历共享内存中的监听结构信息，并根据遍历结果确定待监听的端口标识；监听单元，用于向端口监听进程发送包含所述端口标识的端口监听请求，并接收所述端口监听进程针对所述端口监听请求反馈的文件描述符；请求处理单元，用于调用预设接收接口获取所述文件描述符处的请求，并处理获取的所述请求。

为实现上述目的，本申请另一方面还提供一种服务器，所述服务器包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，实现上述的端口监听方法。

由上可见，本申请一个或者多个实施方式提供的技术方案，主进程可以创建端口监听进程，该端口监听进程可以用于动态地监听新增端口。具体地，当出现端口变更时，针对新增端口，端口监听进程可以先判断该新增端口是否已经完成了初始化，或没有，可以获取该新增端口的端口信息。在实际应用中，端口信息可以监听IP地址、监听端口号、套接字对应的读写缓冲区大小、TCP网络拥塞参数控制等信息。针对获取的端口信息，端口监听进程可以对其进行初始化，并将生成的监听结构信息存储于共享内存中。工作进程可以定时检测共享内存中的监听结构信息，如果存在未生效的监听结构信息，可以向端口监听进程发送对应的端口监听请求。端口监听进程接收到该端口监听请求之后，可以在确保对应的目标监听结构信息完成监听的情况下，向工作进程反馈监听得到的文件描述符。这样，工作进程便可以根据文件描述符，通过新生效的端口处理各项请求，从而完成端口变更的过程。可见，通过工作进程与端口监听进程的协同运作，可以在端口发生变更时再进行初始化和监听的过程，不仅节省了系统的资源消耗，还能够及时地生效变更后的端口，保证了加速服务的稳定性和及时性。

附图说明

为了更清楚地说明本发明实施方式中的技术方案，下面将对实施方式描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施方式中的系统结构示意图；

图2是本发明实施方式中端口监听进程执行的动态监听端口的步骤示意图；

图3是本发明实施方式端口监听进程执行的流程示意图；

图4是本发明实施方式中工作进程执行的动态监听端口的步骤示意图；

图5是本发明实施方式工作进程执行的流程示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施方式及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施方式仅是本申请一部分实施方式，而不是全部的实施方式。基于本申请中的实施方式，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式，都属于本申请保护的范围。

本申请提供的端口监听方法，可以应用于如图1所示的系统架构中。在CDN的节点服务器、负载均衡器以及代理服务器等设备中，都可以部署该系统架构。举例来说，当前的CDN中，nginx架构由于高性能和较高的稳定性，被广泛地应用于节点服务器、负载均衡器以及代理服务器等设备中。本申请以nginx架构为例，阐述该端口监听方法。在本申请中，主进程(master进程)可以创建出工作进程(worker进程)和端口监听进程，并且主进程可以创建共享内存。不同于进程堆内存，共享内存中的信息可以在不同的进程之间(例如多个工作进程之间，或者工作进程与端口监听进程之间)共享。其中，工作进程可以负责处理已生效的端口处接收到的请求，端口监听进程则可以动态地对出现变更的端口进行监听。

在实际应用中，工作进程与端口监听进程之间，可以通过双向管道进行通信。工作进程可以通过该双向管道，向端口监听进程发送端口监听请求，而端口监听进程可以通过该双向管道，向工作进程反馈端口的监听结果。

具体地，请参阅图2和图3，本申请一个实施方式提供的端口监听方法，可以应用于上述的端口监听进程中，该方法可以包括以下多个步骤。

S11：在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中。

在本实施方式中，端口监听进程可以持续检测当前的系统中，是否存在新增端口。该新增端口可以是除当前已生效的端口之外的端口，通常而言，当加速域名的端口发生变更时，可能会出现新增端口。针对新增端口，端口监听进程可以先判断该新增端口是否已经被初始化过。这里判断新增端口是否被初始化过的依据，是在共享内存中查询是否具备该新增端口的初始化信息。若在共享内存中存在新增端口的初始化信息，那么就表明该新增端口被初始化过，而如果在共享内存中不存在新增端口的初始化信息，则表明该新增端口是首次被启用，目前还没有对其进行初始化。

在本实施方式中，如果该新增端口未被初始化，端口监听进程可以对该新增端口进行初始化处理，并将初始化得到的结果写入共享内存中。具体地，端口监听进程可以获取该新增端口的端口信息，该端口信息例如可以包括监听IP地址、监听端口号、套接字对应的读写缓冲区大小、何时触发缓冲区可读可写就绪、accept连接队列、TCP网络拥塞参数控制等。在获取到新增端口的端口信息后，端口监听进程可以在共享内存中将端口信息处理为配置信息结构。在实际应用中，该配置信息结构可以是ngx_http_conf_port_t结构。然后，端口监听进程可以调用初始化监听接口ngx_http_init_listening接口，对ngx_http_conf_port_t结构进行初始化，从而生成端口信息对应的监听结构信息，该监听结构信息例如可以是ngx_listening_t信息。

在生成监听结构信息后，该监听结构信息可以被写入共享内存中，这样处理的有益之处在于，若当前的端口监听进程出现异常，当前的端口监听进程就需要退出系统，而主进程会新启用一个端口监听进程继续服务。此时，之前完成初始化的监听结构信息不会随着退出的端口监听进程而失效，而是依然存储在共享内存中。新启用的端口监听进程可以从共享内存中读取已生成的监听结构信息，从而保持服务的连贯性。

S13：接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听。

在本实施方式中，当端口监听进程接收到工作进程发来的端口监听请求时，可以从该端口监听请求中识别目标监听结构信息的端口标识。该端口标识的实现方式多种多样，可以是目标监听结构信息的名称，也可以是目标监听结构信息名称中的下标。例如，该端口标识可以是名称A₁₁，也可以是下标11。当然，在实际应用中，该端口标识还可以有其它更多的表现形式，这里就不一一例举了。

在本实施方式中，在接收到工作进程发来的端口监听请求后，端口监听进程可以判断目标监听结构信息是否已经完成监听。具体地，端口监听进程可以在进程堆内存中初始化一个向量数组，该向量数组可以用于记录各个监听结构信息的监听状态。其中，监听状态可以分为已监听和未监听。根据目标监听结构信息的端口标识，可以从向量数据中读取该目标监听结构信息对应的监听状态，从而可以基于该监听状态判断目标监听结构信息是否已完成监听。

在本实施方式中，如果目标监听结构信息未完成监听，那么对应的端口就没有生效。此时，端口监听进程可以创建目标监听结构信息对应的链接套接字，并可以将目标监听结构信息中的通信地址绑定至该链接套接字上。具体地，端口监听进程可以创建Linux的socket，然后将通过调用bind，将ngx_listening_t中的监听ip地址和监听端口绑定至socket上。然后，端口监听进程可以调用预设监听接口对绑定了通信地址的链接套接字进行监听，从而得到监听成功的文件描述符。其中，预设监听接口可以是Linux的listen接口，通过调用该接口可以对链接套接字完成监听，从而得到对应的文件描述符。

在本实施方式中，在得到监听成功的文件描述符后，端口监听进程可以将该文件描述符写入上述的向量数组中，并可以将向量数组中目标监听结构信息的监听状态修改为已监听。这样，如果后续有其它的工作进程发来针对该目标监听结构信息的端口监听请求，端口监听进程可以直接将向量数组中对应的文件描述符提供给工作进程，从而加快响应速度。此外，存储于向量数据中的文件描述符是不会关闭回收的，那么即使工作进程出现异常无法工作时，端口监听进程处的文件描述符依然可以接收新请求的接入，从而保证了端口服务的连续性。

S15：在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。

在本实施方式中，若目标监听结构信息已完成监听，那么在端口监听进程处便会具备对应的文件描述符，此时，端口监听进程可以调用Linux的sendmsg接口，将监听得到的文件描述符通过双向管道反馈给工作进程。工作进程接收到文件描述符后，便可以调用Linux的accept接口，接收该文件描述符进来的请求，并可以处理这些请求，从而使得新增端口能够生效。

在实际应用中，在上述步骤执行时，如果出现接口调用失败的情况，端口监听进程便可以调用reload接口，通知主进程需要重新加载配置，并启用新的端口监听进程来执行上述的方案。

由上可见，文件描述符可以跨进程传递，端口监听进程监听的文件描述符可以传递给工作进程，从而能够实现初始化过程和数据接收过程互相独立，使得新增端口的过程不影响业务处理，从而提高响应性能。并且可以简化进程职责，解决数据耦合的问题，从而解决权限验证等一系列问题，能够提高软件的稳定性。

此外，端口监听进程和工作进程采用双向数据通信的方式，对于任意一进程崩溃的情况，端口数据都能很好地恢复，进而提高了软件稳定性。并且结合文件描述符的缓存，使得进程崩溃恢复时，能够保证端口接入的连续性，不会因为一个进程崩溃，该端口就接收不了新请求。

在本申请中，可以使用共享内存来存储不同进程都要使用的共有信息，而不是通过接口传递这些共有数据，接口只传递目标监听结构信息的端口标识等与业务无关的数据，这样不但提高了消息交互效率，提高了软件性能，而且提高了安全性，避免接口暴露使得数据泄露。

本申请还提供一种端口监听系统，所述系统包括：

初始化单元，用于在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中；

判断单元，用于接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听；

反馈单元，用于在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。

在本申请另一个实施方式中，还可以提供应用于工作进程的端口监听方法，请参阅图4和图5，该方法可以包括以下多个步骤。

S21：遍历共享内存中的监听结构信息，并根据遍历结果确定待监听的端口标识。

在本实施方式中，工作进程可以设置一个定时器，定时遍历共享内存中的监听结构信息，从而判断是否有需要进行监听的监听结构信息。在实际应用中，如果一个工作进程从一开始就稳定工作，那么通常只有在发生端口变更时，才会从共享内存中查询到需要监听的监听结构信息。而如果一个工作进程出现异常退出了，那么对于新启用的工作进程而言，共享内存中的大部分监听结构信息可能都需要进行监听(因为要延续之前工作进程的进度)。在实际应用中，当定时器到达设定的时间，或者工作进程在第一次启用时，都可以主动去遍历共享内存中的监听结构信息。对于当前已经生效的端口而言，工作进程内可以记录这些端口的生效状态。当工作进程在遍历共享内存中的监听结构信息时，可以判断各个监听结构信息对应的端口是否具备已生效的状态。如果具备，则表示已经对监听结构信息完成了监听，而如果某个监听结构信息不具备已生效的状态，则表示该监听结构信息需要进行进一步的监听过程。

在实际应用中，当端口发生变更时，端口监听进程刚写入共享内存中的监听结构信息通常是不具备已生效状态的，因此工作进程可以针对这部分监听结构信息发起端口监听请求。此外，如果一个工作进程是新启用的，那么由于没有任何监听结构信息的已生效状态，因此对于共享内存中已存在的监听结构信息，该工作进程都需要发起端口监听请求。

在一个实施方式中，工作进程可以在遍历结果中识别未生效的监听结构信息，并获取未生效的监听结构信息对应的端口标识，获取的端口标识便可以作为待监听的端口标识。其中，端口标识的实现方式多种多样，可以是监听结构信息的名称，也可以是监听结构信息名称中的下标。例如，该端口标识可以是名称A₁₁，也可以是下标11。当然，在实际应用中，该端口标识还可以有其它更多的表现形式，这里就不一一例举了。

S23：向端口监听进程发送包含所述端口标识的端口监听请求，并接收所述端口监听进程针对所述端口监听请求反馈的文件描述符。

在本实施方式中，在确定了待监听的端口标识后，工作进程便可以向端口监听进程发送包含这些端口标识的端口监听请求。端口监听进程在接收到端口监听请求之后，可以根据上述的步骤，对监听结构信息完成初始化，并得到对应的文件描述符(当然，如果监听结构信息本身已经完成初始化，那么可以直接从向量数组中读取对应的文件描述符即可)，并可以将文件描述反馈给工作进程。

在本实施方式中，工作进程可以在进程堆内存中记录端口标识的发送状态及发送时间节点。这样处理的目的在于，可以避免对同一个端口标识重复发送端口监听请求，也可以监控针对某个端口标识发送端口监听请求后的时长。在下一次遍历共享内存中的监听结构信息时，工作进程可以读取进程堆内存中记录的发送状态和发送时间节点，从而判断是否有端口标识的请求超时了。具体地，针对目标端口标识，若在指定时长内未接收到端口监听进程反馈的文件描述符，则表示针对目标端口标识的端口监听请求超时了，此时端口监听进程可能存在异常，因此工作进程可以向主进程发送超时通知，主进程在核实后可以进行重载配置或者重启端口监听进程的步骤。

在本申请中，每个进程都可以具备自身的进程堆内存，通常而言，进程堆内存中的数据无法进行跨进程访问。例如，工作进程A和工作进程B可以分别具备堆内存A和堆内存B，那么工作进程A可以对堆内存A中的数据进行读写操作，同理，工作进程B可以对堆内存B中的数据进行读写操作，但工作进程A无法对堆内存B中的数据进行读写操作，以及工作进程B也无法对堆内存A中的数据进行读写操作。而共享内存中的数据，可供不同的进程进行访问。例如，存储于共享内存中的数据，可以被不同的工作进程访问，也可以被工作进程和主进程访问。

S25：调用预设接收接口获取所述文件描述符处的请求，并处理获取的所述请求。

在本实施方式中，端口监听进程可以调用Linux的sendmsg接口，将监听得到的文件描述符通过双向管道反馈给工作进程。工作进程接收到文件描述符后，便可以调用Linux的accept接口，接收该文件描述符进来的请求，并可以处理这些请求，从而使得新增端口能够生效。上述的Linux的accept接口，便可以是预设接收接口。

在一个实施方式中，若当前的工作进程出现异常，新启用的工作进程在启用时，可以主动去遍历共享内存中的监听结构信息，若其中的一个或者多个监听结构信息在新启用的工作进程中不存在对应的文件描述符，新启用的工作进程可以向端口监听进程发送端口监听请求，该端口监听请求中便可以包含上述的一个或者多个监听结构信息的端口标识，从而保持服务的连续性。

本申请还提供一种端口监听系统，所述系统包括：

遍历单元，用于遍历共享内存中的监听结构信息，并根据遍历结果确定待监听的端口标识；

监听单元，用于向端口监听进程发送包含所述端口标识的端口监听请求，并接收所述端口监听进程针对所述端口监听请求反馈的文件描述符；

请求处理单元，用于调用预设接收接口获取所述文件描述符处的请求，并处理获取的所述请求。

本申请还提供一种服务器，所述服务器包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，实现上述的端口监听方法。

上述的服务器可以是部署有nginx系统的服务器，该服务器可以是CDN节点服务器，也可以是CDN中的负载均衡服务器，还可以是CDN中的代理服务器等。

由上可见，本申请一个或者多个实施方式提供的技术方案，主进程可以创建端口监听进程，该端口监听进程可以用于动态地监听新增端口。具体地，当出现端口变更时，针对新增端口，端口监听进程可以先判断该新增端口是否已经完成了初始化，或没有，可以获取该新增端口的端口信息。在实际应用中，端口信息可以监听IP地址、监听端口号、套接字对应的读写缓冲区大小、TCP网络拥塞参数控制等信息。针对获取的端口信息，端口监听进程可以对其进行初始化，并将生成的监听结构信息存储于共享内存中。工作进程可以定时检测共享内存中的监听结构信息，如果存在未生效的监听结构信息，可以向端口监听进程发送对应的端口监听请求。端口监听进程接收到该端口监听请求之后，可以在确保对应的目标监听结构信息完成监听的情况下，向工作进程反馈监听得到的文件描述符。这样，工作进程便可以根据文件描述符，通过新生效的端口处理各项请求，从而完成端口变更的过程。可见，通过工作进程与端口监听进程的协同运作，可以在端口发生变更时再进行初始化和监听的过程，不仅节省了系统的资源消耗，还能够及时地生效变更后的端口，保证了加速服务的稳定性和及时性。

本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。尤其，针对系统和服务器的实施方式来说，均可以参照前述方法的实施方式的介绍对照解释。

本领域内的技术人员应明白，本发明的实施方式可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施方式、完全软件实施方式、或结合软件和硬件方面的实施方式的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施方式的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施方式而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (13)

1.一种端口监听方法，其特征在于，所述方法应用于端口监听进程中，所述方法包括：

在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中；

接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听；

在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。

2.根据权利要求1所述的方法，其特征在于，对所述端口信息初始化包括：

在所述共享内存中将所述端口信息处理为配置信息结构，并调用初始化监听接口，对所述配置信息结构进行初始化，以生成所述端口信息对应的监听结构信息。

3.根据权利要求1或2所述的方法，其特征在于，所述端口监听进程在进程堆内存中初始化向量数组，所述向量数组用于记录各个监听结构信息的监听状态；

判断所述目标监听结构信息是否已完成监听包括：

从所述向量数据中读取所述目标监听结构信息对应的监听状态，并基于所述监听状态判断所述目标监听结构信息是否已完成监听。

4.根据权利要求1所述的方法，其特征在于，若所述目标监听结构信息未完成监听，所述方法还包括：

创建所述目标监听结构信息对应的链接套接字，并将所述目标监听结构信息中的通信地址绑定至所述链接套接字上；

调用预设监听接口对绑定了通信地址的所述链接套接字进行监听，得到监听成功的文件描述符。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

将监听成功的所述文件描述符写入由所述端口监听进程在进程堆内存中创建的向量数组中；其中，若所述工作进程出现异常，所述向量数组中的文件描述符依然接收新请求的接入。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若当前的端口监听进程出现异常，新启用的端口监听进程从所述共享内存中读取已生成的监听结构信息。

7.一种端口监听系统，其特征在于，所述系统包括：

初始化单元，用于在出现新增端口时，若所述新增端口未被初始化，获取所述新增端口的端口信息，并对所述端口信息初始化后，将生成的监听结构信息存储于共享内存中；

判断单元，用于接收工作进程发来的针对目标监听结构信息的端口监听请求，并判断所述目标监听结构信息是否已完成监听；

反馈单元，用于在确认所述目标监听结构信息已完成监听的情况下，将监听得到的文件描述符反馈给所述工作进程，以使得所述工作进程通过新生效的端口处理请求。

8.一种端口监听方法，其特征在于，所述方法应用于工作进程中，所述方法包括：

遍历共享内存中的监听结构信息，并根据遍历结果确定待监听的端口标识；

向端口监听进程发送包含所述端口标识的端口监听请求，并接收所述端口监听进程针对所述端口监听请求反馈的文件描述符；

调用预设接收接口获取所述文件描述符处的请求，并处理获取的所述请求。

9.根据权利要求8所述的方法，其特征在于，根据遍历结果确定待监听的端口标识包括：

在遍历结果中识别未生效的监听结构信息，并获取所述未生效的监听结构信息对应的端口标识；其中，获取的所述端口标识作为待监听的端口标识。

10.根据权利要求8所述的方法，其特征在于，在向端口监听进程发送包含所述端口标识的端口监听请求之后，所述方法还包括：

在进程堆内存中记录所述端口标识的发送状态及发送时间节点，针对目标端口标识，若在指定时长内未接收到所述端口监听进程反馈的文件描述符，向主进程发送超时通知。

11.根据权利要求8所述的方法，其特征在于，所述方法还包括：

若当前的工作进程出现异常，新启用的工作进程遍历所述共享内存中的监听结构信息，若其中的一个或者多个监听结构信息在所述新启用的工作进程中不存在对应的文件描述符，所述新启用的工作进程向所述端口监听进程发送端口监听请求，所述端口监听请求中包含所述一个或者多个监听结构信息的端口标识。

12.一种端口监听系统，其特征在于，所述系统包括：

遍历单元，用于遍历共享内存中的监听结构信息，并根据遍历结果确定待监听的端口标识；

监听单元，用于向端口监听进程发送包含所述端口标识的端口监听请求，并接收所述端口监听进程针对所述端口监听请求反馈的文件描述符；

请求处理单元，用于调用预设接收接口获取所述文件描述符处的请求，并处理获取的所述请求。

13.一种服务器，其特征在于，所述服务器包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1至6及8至11中任一所述的方法。

Images