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