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



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