Http: make ngx_http_init_listening a public api

胡聪 (hucc) hucong.c at
Sun May 21 17:17:40 UTC 2017


On Saturday, May 20, 2017 1:55 AM +0300, Maxim Dounin wrote:

>On Fri, May 19, 2017 at 03:04:43AM +0800, 0 at wrote:
>> Thank you for your reply.
>> ********
>> Please let me assume it make sense to make nginx work as a
>> standalone websock server. The problem we will face is that we
>> cannot send message to client. Because when the client initial
>> tcp connection, the connection will be processed by one worker
>> uncertainly. If we want push message to one client, we must find
>> the worker processing this client connection.
>> *********
>> It is also impossible to add new listening port to an http
>> server directive dynamically in the websocket model, but it will
>> be a huge burden to sync this logic to the http model. So I
>> propose nginx to open this api.
>Thank you for the detailed explanation.
>So, you are trying to introduce per-process listening sockets in
>order to be able to communicate with a particular worker process.
>This is highly unlikely to work properly without deep integration
>with nginx itself, and/or will be broken by trivial unrelated
>changes in nginx.  So the answer is still negative.
>If you want to try to address the problem properly, consider the
>following approaches:
>- create listening sockets yourself, and handle connections in
>  your module;
>- introduce per-process listining sockets in nginx core; likely
>  there will many obscure problems though, including things like
>  what to do on graceful shutdown;
>- use interprocess communication instead - for example, nginx has
>  shared memory available to modules (there are also channels to
>  pass messages between processes, but these are not currently
>  available to modules).

It is necessary to introduce per-process listening sockets in nginx core.
Laster year, I have done most of the work, when I found it is hard to establish
the connection to push data to another process in ngx_rtmp_auto_push_moudle.
The problem can be solved by introduce a flag aloneport in ngx_listening_t and
work with ls->worker. The configuration is listen ** [aloneport=ngx_worder].
And as far as I know, there is an obscure problem which is what to do on reload
when new worker_processes number is less than the no-update ngx_worker of
aloneport. As for the problem about what to do on graceful shutdown, I still
don`t get it. Besides, I hope that arut will provide some ideas.
Another problem/idea found in ngx_rtmp_module, it is also necessary to introduce
a config options like NGX_3RD_CORE_MODULES (or other way or options) to ensure
the 3rd party CORE modules is behind ngx_events_module. It is going to solve
some obscure problems where the solution in ngx_rtmp_module is unfriendly
and incomprehensible.

If you guys also think it is needed, I will provide the patch of aloneport
once time permits.

Best wishes

nginx-devel mailing list
nginx-devel at

More information about the nginx-devel mailing list