Http: make ngx_http_init_listening a public api
0 at lvht.net
0 at lvht.net
Thu May 18 19:04:43 UTC 2017
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.
Please forgive me for my poor English.
> On 19 May 2017, at 01:50, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> On Fri, May 19, 2017 at 01:12:29AM +0800, 0 at lvht.net wrote:
>> Is there any maintainer who could review this patch? Thanks.
> I don't think this change is needed. Listening sockets are to be
> created using the "listen" directive of the core module, they are
> not expected to be added by other modules.
> If you think that this is needed, you may try to convince me
> and/or other developers by providing more details on how do you
> want to use it and why it is needed.
>>> 在 2017年5月1日，08:31，nginx-devel-bounces at nginx.org 写道：
>>> # HG changeset patch
>>> # User 吕海涛 <0 at lvht.net>
>>> # Date 1493595577 -28800
>>> # Mon May 01 07:39:37 2017 +0800
>>> # Node ID 2ddd0894c1a6c7efe45310b874a5b4091b58bb81
>>> # Parent f38647c651a8d5c884b5aacc9f9a5b1af196309b
>>> Http: make ngx_http_init_listening a public api
>>> Make this api public is a good convenience to allow other module
>>> add listening port to http server dynamically.
>>> diff -r f38647c651a8 -r 2ddd0894c1a6 src/http/ngx_http.c
>>> --- a/src/http/ngx_http.c Thu Apr 27 16:57:18 2017 +0300
>>> +++ b/src/http/ngx_http.c Mon May 01 07:39:37 2017 +0800
>>> @@ -55,8 +55,6 @@ static ngx_int_t ngx_http_cmp_conf_addrs
>>> static int ngx_libc_cdecl ngx_http_cmp_dns_wildcards(const void *one,
>>> const void *two);
>>> -static ngx_int_t ngx_http_init_listening(ngx_conf_t *cf,
>>> - ngx_http_conf_port_t *port);
>>> static ngx_listening_t *ngx_http_add_listening(ngx_conf_t *cf,
>>> ngx_http_conf_addr_t *addr);
>>> static ngx_int_t ngx_http_add_addrs(ngx_conf_t *cf, ngx_http_port_t *hport,
>>> @@ -1623,7 +1621,7 @@ ngx_http_cmp_dns_wildcards(const void *o
>>> -static ngx_int_t
>>> ngx_http_init_listening(ngx_conf_t *cf, ngx_http_conf_port_t *port)
>>> ngx_uint_t i, last, bind_wildcard;
>>> diff -r f38647c651a8 -r 2ddd0894c1a6 src/http/ngx_http.h
>>> --- a/src/http/ngx_http.h Thu Apr 27 16:57:18 2017 +0300
>>> +++ b/src/http/ngx_http.h Mon May 01 07:39:37 2017 +0800
>>> @@ -80,6 +80,7 @@ ngx_int_t ngx_http_add_location(ngx_conf
>>> ngx_http_core_loc_conf_t *clcf);
>>> ngx_int_t ngx_http_add_listen(ngx_conf_t *cf, ngx_http_core_srv_conf_t *cscf,
>>> ngx_http_listen_opt_t *lsopt);
>>> +ngx_int_t ngx_http_init_listening(ngx_conf_t *cf, ngx_http_conf_port_t *port);
>>> void ngx_http_init_connection(ngx_connection_t *c);
>>> nginx-devel mailing list
>>> nginx-devel at nginx.org
>> nginx-devel mailing list
>> nginx-devel at nginx.org
> Maxim Dounin
> nginx-devel mailing list
> nginx-devel at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel