Http: make ngx_http_init_listening a public api
0 at lvht.net
0 at lvht.net
Sat May 20 02:58:03 UTC 2017
> On 20 May 2017, at 01:56, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> 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
>> 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
> nginx-devel mailing list
> nginx-devel at nginx.org
More information about the nginx-devel