Http: make ngx_http_init_listening a public api

[Maxim Dounin]

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/