Http: make ngx_http_init_listening a public api

[胡聪 (hucc)]

Hi,

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

>On Fri, May 19, 2017 at 03:04:43AM +0800, 0 at lvht.net 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
-hucc

_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel