Http: make ngx_http_init_listening a public api

[吕海涛]

Hello!

What I still want to point out is that the job of the ngx_http_init_listening
is not bind and listen on some certain tcp port waiting for incoming http 
request, but init the structs about listening adders and ports, associate
them with http server and push the listening struct into the 
cycle->listening list. And all the process has been finished before the
event module startup.

As I am trying to introduce pre-process http listening sockets, I have to
create listening socket during the worker process startup. And I have to
init all the structs about listening address and port, and associate them
with corresponding http server, and push the listening struct into the
cycle->listening list. So when the push http request is coming, nginx will
choose the right http server to handle the request. 

All the work has been done well by the nix_http_init_listening api.So I
proposed to open this api. If I do all these job on my own module, I 
would reinvent a new nix_http_init_listening api.

Introducing pre-process listening socket support in nginx core is cool, but 
more completed. And it is both hard to be implemented and to be merged.

The share-memory solution will make the work model more complex and
less efficient. I would like to separate worker process as much as possible.

So I would like to choose the first approach you offered. It is more simple
and clear.

The nchan module seems awesome. And I will make more research on it.

Thanks.


> On 20 May 2017, at 01:55, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> Hello!
> 
> On Fri, May 19, 2017 at 03:04:43AM +0800, 0 at lvht.net <mailto:0 at lvht.net> wrote:
> 
>> Thank you for your reply. 
>> 
>> As a client oriented proxy server, nginx will boot several 
>> worker process to listen on the same port. If a tcp connection 
>> is initiated, this connection will be processed by one worker. 
>> This model is simple yet efficient. However this model makes it 
>> impossible to let nginx work as a standalone server of some 
>> protocols, for example, websocket.
>> 
>> 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.
>> 
>> I have a simple idea. If we add an additional unique listen port 
>> for each http server directive before worker process do the 
>> event loop dynamically, we could use the added port to send 
>> message to client. As the listen directive is processed in the 
>> master process, it does make any help.
>> 
>> Talk is cheap. I just make a prototype at 
>> https://github.com/lvht/nginx-websocket-module
>> 
>> This model makes nginx as a standalone websocket server, and 
>> business logic free as soon as possible.
>> 
>> The idea of adding unique listening port dynamically is a 
>> practical solution for any protocol which need to send data to 
>> message initially, websocket, sse, http poll, etc..
>> 
>> 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).
> 
> You may also want to look into Nchan module by Leo Ponomarev, it 
> is expected to contain some solutions to the problems you are 
> working on.
> 
> -- 
> Maxim Dounin
> http://nginx.org/ <http://nginx.org/>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org <mailto:nginx-devel at nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-devel <http://mailman.nginx.org/mailman/listinfo/nginx-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170520/5113ceb1/attachment-0001.html>