Http: make ngx_http_init_listening a public api

[0 at lvht.net]

> On 20 May 2017, at 01:56, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> Hello!
> 
>> On Fri, May 19, 2017 at 03:04:43AM +0800, 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/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel