Hello! On Mon, May 22, 2017 at 01:17:40AM +0800, 胡聪 (hucc) wrote:
> Hi, > > On Saturday, May 20, 2017 1:55 AM +0300, Maxim Dounin wrote: > > >On Fri, May 19, 2017 at 03:04:43AM +0800, [email protected] wrote: > > > >> Thank you for your reply. > >> ******** > >> 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. > >> ********* > >> 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). > > It is necessary to introduce per-process listening sockets in nginx core. > Laster year, I have done most of the work, when I found it is hard to > establish > the connection to push data to another process in ngx_rtmp_auto_push_moudle. > The problem can be solved by introduce a flag aloneport in ngx_listening_t and > work with ls->worker. The configuration is listen ** [aloneport=ngx_worder]. > And as far as I know, there is an obscure problem which is what to do on > reload > when new worker_processes number is less than the no-update ngx_worker of > aloneport. As for the problem about what to do on graceful shutdown, I still > don`t get it. Besides, I hope that arut will provide some ideas. > Another problem/idea found in ngx_rtmp_module, it is also necessary to > introduce > a config options like NGX_3RD_CORE_MODULES (or other way or options) to ensure > the 3rd party CORE modules is behind ngx_events_module. It is going to solve > some obscure problems where the solution in ngx_rtmp_module is unfriendly > and incomprehensible. > > If you guys also think it is needed, I will provide the patch of aloneport > once time permits. I personally think that per-process listening sockets is not a good solution from architectural point of view - while they provide something immediate and easy-to-use, they 1) introduce (likely unsolvable) problems during shutdown / configuration reload, and 2) they don't really solve anything as long as the problem is a little bit more complicated than "send something to one client" - for example, it is not possible to send something to a group of clients. Not to mention that it is very non-trivial to use if you don't know ports in advance, and also breaks basic nginx model of multiple identical worker processes. So, just for the record: I don't think it is needed, and would rather suggest to improve interprocess communications instead. I can be convinced that it is needed though, as long as benefits are clearly demonstrated and downsides are understood and addressed somehow. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
