Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1504681
  • 博文数量: 228
  • 博客积分: 1698
  • 博客等级: 上尉
  • 技术积分: 3241
  • 用 户 组: 普通用户
  • 注册时间: 2008-12-24 21:49
个人简介

Linux

文章分类

全部博文(228)

文章存档

2017年(1)

2016年(43)

2015年(102)

2014年(44)

2013年(5)

2012年(30)

2011年(3)

分类: LINUX

2015-12-01 23:32:05

很好奇nginx如何处理异步请求,我看nginx-rtmp在处理异步时状态也还行,所以调试下看看。
纯异步做rtmp协议,真是非常复杂,特别是需要做回源。无数的回调和处理逻辑。NGINX-RTMP几个简化问题的方法:
1. RTMP-CHUNK协议解析直接在一个函数里做,避免添加状态。
2. CHUNK的长度可以计算得出,所以收到要求的长度的数据后,才开始协议解析。
3. 收发数据,协议解析,包逻辑处理,三部分分离。
4. 包收到后通过各种handler回调,包发送时只是发送到chain,异步的发送和包发送分离。
5. 使用ATM模型来收发数据。

6. 使用chain作为收发数据的缓存。收取时,chain达到长度才开始处理;发送包时,缓存到chain,然后启动异步发送即可。
整个机制虽然有所简化,比起同步的调用,要复杂至少10倍。

首先,下载和解压nginx:
     tar xf nginx-1.5.0.tar.gz && tar xf nginx-rtmp-module-1.0.4.tar.gz
     cd nginx-1.5.0 && ./configure --add-module=/home/winlin/nginx-rtmp-module-1.0.4 --with-http_ssl_module --prefix=`pwd`/release
修改编译参数,将优化去掉:
     sed -i "s/-O /-O0 /g" objs/Makefile
编译:
     make && make install
配置RTMP:
     vi conf/nginx.conf
添加如下:
    daemon off;
    master_process off;
    rtmp {
        server {
            listen 19352;
            application live {
                live on;
                allow publish all;
                allow play all;
            }
        }
    }
配置可以在nginx.c中看到:
    { ngx_string("daemon"),
      NGX_MAIN_CONF|NGX_DIRECT_CONF|NGX_CONF_FLAG,
      ngx_conf_set_flag_slot,
      0,
      offsetof(ngx_core_conf_t, daemon),
      NULL },
跳到函数:ngx_conf_set_flag_slot,可以看到应该配置为on或off。
开始调试。

ultimate IDE的project如附件:

目录结构如下:
E:\Chnvideo\research\nginx
main
nginx-1.5.0
nginx-rtmp-module-1.0.4
只要将nginx和rtmp模块解压到这个目录,然后将当前目录(E:\Chnvideo\research\nginx)在IDE打开即可。
IDE=>New assembly => package nests 输入:E:\Chnvideo\research\nginx

Rtmp模块初始化
rtmp模块初始化函数调用如下:
(gdb) bt
#0  ngx_rtmp_optimize_servers (cf=0x7fffffffe1d0, ports=0x7fffffffddb0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp.c:605
#1  0x00000000004ae362 in ngx_rtmp_block (cf=0x7fffffffe1d0, cmd=0x711680, conf=0xa4da78) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp.c:312
#2  0x000000000041f173 in ngx_conf_handler (cf=0x7fffffffe1d0, last=1) at src/core/ngx_conf_file.c:387
#3  0x000000000041ed1e in ngx_conf_parse (cf=0x7fffffffe1d0, filename=0xa4ce00) at src/core/ngx_conf_file.c:243
#4  0x000000000041b9cc in ngx_init_cycle (old_cycle=0x7fffffffe310) at src/core/ngx_cycle.c:268
#5  0x0000000000406230 in main (argc=1, argv=0x7fffffffe5d8) at src/core/nginx.c:333
(gdb) f
#0  ngx_rtmp_optimize_servers (cf=0x7fffffffe1d0, ports=0x7fffffffddb0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp.c:605
605                 ls->handler = ngx_rtmp_init_connection;
默认将accept之后的处理函数设置为了ngx_rtmp_init_connection。

Nginx的回调函数
在ngx_rtmp_init_connection(ngx_rtmp_init.c:132)中设置断点,可以看到接受连接和处理handshake的过程。
#0  ngx_rtmp_init_connection (c=0x7ffff7fad190) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_init.c:31
#1  0x000000000042befe in ngx_event_accept (ev=0xa7b370) at src/event/ngx_event_accept.c:357
#2  0x0000000000435d26 in ngx_epoll_process_events (cycle=0xa4cca0, timer=18446744073709551615, flags=1) at src/event/modules/ngx_epoll_module.c:683
#3  0x0000000000428f02 in ngx_process_events_and_timers (cycle=0xa4cca0) at src/event/ngx_event.c:249
#4  0x0000000000433181 in ngx_single_process_cycle (cycle=0xa4cca0) at src/os/unix/ngx_process_cycle.c:315
#5  0x00000000004064c8 in main (argc=1, argv=0x7fffffffe5d8) at src/core/nginx.c:409
在ngx_event_accept(ngx_event_accept.c:206)中,接受到连接后进行处理,其中设置了recvchain:
        c->recv_chain = ngx_recv_chain;
        c->send_chain = ngx_send_chain;
这两个值是宏定义,在ngx_event.h:458:
extern ngx_os_io_t  ngx_io;
#define ngx_recv_chain       ngx_io.recv_chain
#define ngx_send_chain       ngx_io.send_chain
这个ngx_io是个extern的变量,grep搜索,发现定义在:
[winlin@dev6 nginx-1.5.0]$ find src -name "*.c"|xargs grep -in "ngx_io\;"
src/core/ngx_connection.c:13:ngx_os_io_t  ngx_io;
[winlin@dev6 nginx-1.5.0]$ find src -name "*.c"|xargs grep -in "ngx_io ="|grep epoll
src/event/modules/ngx_epoll_module.c:329:    ngx_io = ngx_os_io;
所以会在epoll这个模块被重置,可以设置断点。
b ngx_epoll_module.c:329
Breakpoint 6, ngx_epoll_init (cycle=0xa4cca0, timer=0) at src/event/modules/ngx_epoll_module.c:329
329         ngx_io = ngx_os_io;
(gdb) p &ngx_io
$32 = (ngx_os_io_t *) 0xa222a0
(gdb) p &ngx_os_io
$33 = (ngx_os_io_t *) 0x703440
(gdb) p ngx_os_io
$34 = {recv = 0x42f8b0 , recv_chain = 0x42f9c8 , udp_recv = 0x42fc74 , send = 0x42fd34 , send_chain = 0x435ee4 , flags = 1}
(gdb) p ngx_io
$35 = {recv = 0, recv_chain = 0, udp_recv = 0, send = 0, send_chain = 0, flags = 0}
在connection.c中的初始化只是默认初始化为0,只有在ngx_os_io这个里面才是真正用到的。
这个ngx_os_io是在这里定义的:
[winlin@dev6 nginx-1.5.0]$ find src -name "*.c"|xargs grep -in "ngx_os_io \="|grep linux
src/os/unix/ngx_linux_init.c:75:    ngx_os_io = ngx_linux_io;
这个结构体定义为:
static ngx_os_io_t ngx_linux_io = {
    ngx_unix_recv,
    ngx_readv_chain,
    ngx_unix_send,
    ngx_linux_sendfile_chain,
};
函数定义在ngx_readv_chain.c:19和ngx_linux_sendfile_chain.c:38(对于rtmp还是用的writev,不是用的sendfile)。

处理函数的改变
ngx_rtmp_init_connection里面调用了ngx_rtmp_init_session和ngx_rtmp_handshake。
ngx_rtmp_init_session先调用ngx_rtmp_set_chunk_size,然后调用ngx_rtmp_fire_event激发了事件NGX_RTMP_CONNECT。
ngx_rtmp_set_chunk_size,第一次将chunk-size设为128(NGX_RTMP_DEFAULT_CHUNK_SIZE),不需要发包。
ngx_rtmp_fire_event的handler可以搜索:NGX_RTMP_CONNECT,定义在:ngx_rtmp_limit_postconfiguration
h = ngx_array_push(&cmcf->events[NGX_RTMP_CONNECT]);
*h = ngx_rtmp_limit_connect;
所以NGX_RTMP_CONNECT的handler应该是ngx_rtmp_limit_connect,这个函数检查一个共享的变量,然后判断是否超过连接数,返回错误或者OK:
      rc = n > (ngx_uint_t) lmcf->max_conn ? NGX_ERROR : NGX_OK;
若可以接受这个连接,则开始握手,调用函数ngx_rtmp_handshake如下:
#0  ngx_rtmp_handshake (s=0xa665b0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handshake.c:576
#1  0x00000000004af3ab in ngx_rtmp_init_connection (c=0x7ffff7fad190) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_init.c:132
#2  0x000000000042befe in ngx_event_accept (ev=0xa7b370) at src/event/ngx_event_accept.c:357
#3  0x0000000000435d26 in ngx_epoll_process_events (cycle=0xa4cca0, timer=18446744073709551615, flags=1) at src/event/modules/ngx_epoll_module.c:683
#4  0x0000000000428f02 in ngx_process_events_and_timers (cycle=0xa4cca0) at src/event/ngx_event.c:249
#5  0x0000000000433181 in ngx_single_process_cycle (cycle=0xa4cca0) at src/os/unix/ngx_process_cycle.c:315
#6  0x00000000004064c8 in main (argc=1, argv=0x7fffffffe5d8) at src/core/nginx.c:409
在ngx_rtmp_handshake中,初始化rtmp的读写函数为:
c->read->handler =  ngx_rtmp_handshake_recv;
c->write->handler = ngx_rtmp_handshake_send;
然后,设置状态机:
      s->hs_stage = NGX_RTMP_HANDSHAKE_SERVER_RECV_CHALLENGE;
并直接进入下一个状态:
      ngx_rtmp_handshake_recv(c->read);
可见,还是使用了状态机,只是将状态组合成了几个大的阶段,通过设置不同的c->read/write->hander来处理。
在handshake完毕的函数ngx_rtmp_cycle(s)里面,将handler设置成了ngx_rtmp_recv/ngx_rtmp_send。

HandshakeBuffer
设置断点,看状态如何改变:
(gdb) b ngx_rtmp_handshake_recv
Breakpoint 15 at 0x4b0526: file /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handshake.c, line 375.
(gdb) b ngx_rtmp_handshake_send
Breakpoint 16 at 0x4b09a6: file /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handshake.c, line 490.
ngx_rtmp_handshake_recv,接受消息,处理时,先接受指定长度的数据,然后再处理。
b = s->hs_buf;
while (b->last != b->end) {
    n = c->recv(c, b->last, b->end - b->last);
    if (n == NGX_AGAIN) {
        ngx_add_timer(rev, s->timeout);
        if (ngx_handle_read_event(c->read, 0) != NGX_OK) {
            ngx_rtmp_finalize_session(s);
        }
        return;
    }
    b->last += n;
}
第一次时,会收1537字节然后处理,:
     (gdb) p b->end-b->last
      $76 = 1537
所以这个s->hs_buf应该初始化为1537字节,即handshake的字节。在调用handshake时初始化为NGX_RTMP_HANDSHAKE_BUFSIZE长度。

获取时间:
ngx_time_update这个函数会更新全局变量ngx_current_msec,调用的是ngx_gettimeofday,如果过多频繁的调用会有性能问题。
所以应该不会随意调用它,很多时候只是直接用,相当于cache了这个时间。

timer的处理,超时:
假设收取失败,返回的是NGX_AGAIN(-2),则会使用定时器:ngx_add_timer设置超时,然后调用ngx_handle_read_event侦听READ事件。
ngx_add_timer会添加到rbtree里面去:
      timer = {key = 1380262079704, left = 0x719700, right = 0x719700, parent = 0x0, color = 0 '\000', data = 0 '\000'}
NGX_EAGAIN返回后,会调用ngx_event_expire_timers函数,这个会取全局的rbtree的root:ngx_event_timer_rbtree
      (gdb) p ngx_event_timer_rbtree 
      $98 = {root = 0xa7b468, sentinel = 0x719700, insert = 0x414ded }
     (gdb) p *ngx_event_timer_rbtree.root
      $101 = {key = 1380262079704, left = 0x719700, right = 0x719700, parent = 0x0, color = 0 '\000', data = 0 '\000'}
这个root就是ngx_add_timer添加的那个选项,rev就是handshake的那个结构。
rbtree的key是超时时间,所以最小的超时时间会放在前面,ngx_event_add_timer函数里面:
      key = ngx_current_msec + timer;
rbtree的节点是直接指向evt对象的,所以ngx_event_expire_timers可以直接从rbtree的node获取evt:
      ev = (ngx_event_t *) ((char *) node - offsetof(ngx_event_t, timer));
然后设置为timeout后,直接就调用handler:
     ev->timedout = 1;
     ev->handler(ev); // ngx_rtmp_handshake_recv
因为timeout,所以就关掉连接了。

EAGAIN的处理:
假若没有timeout,则进入到EAGAIN的处理。
ngx_event_find_timer会返回一个timeout,共epoll_wait来处理超时事件。
     timer = ngx_event_find_timer(); //60000,handshake的超时为60秒。
     events = epoll_wait(ep, event_list, (int) nevents, timer);
若fd可读,则调用read的handler:
     if ((revents & EPOLLIN) && rev->active) {
          rev = c->read;
          rev->handler(rev);
     (gdb) p *c->read->handler
      $125 = {void (ngx_event_t *)} 0x4b0519
所以直接就调用到了这个处理函数ngx_rtmp_handshake_recv,先清除timer,然后读取到handshake需要的长度的数据。
     (gdb) p b->end-b->last
      $126 = 1437
还需要读取这些数据。若EAGAIN,还是在可读时调用这个函数。
可见nginx来设置不同的handler,相当于将大状态机切割成小状态机,小状态机里面直接switch。
若c++用类表示大状态机,用switch表示小状态机,是可以简化的。设置不同的handler,就设置不同的状态子类表示。

ATM模型:
ATM就是读-写-读这种分离的模型,避免又读又写。即同一时刻,只能读或者写,做完了才能做下一个。
ngx_rtmp_handshake_recv中,会先读取,若EAGAIN则侦听读事件,若读取完毕则删除读事件。
     // start read, if not completed, focus read event.
     n = c->recv(c, b->last, b->end - b->last);
     if (n == NGX_AGAIN) {
          ngx_handle_read_event(c->read, 0);
          return;
     }
     // read completed, donot focus read event.
     if (rev->active) {
          ngx_del_event(rev, NGX_READ_EVENT, 0);
     }
若读取C0C1成功,则发送S0S1S2。调用的是:
     ngx_rtmp_handshake_send(c->write);
这个函数会尝试发送,也是ATM模型:
     // start write, if not completed, focus write event.
     n = c->send(c, b->pos, b->last - b->pos);
     if (n == NGX_AGAIN || n == 0) {
          ngx_handle_write_event(c->write, 0)
          return;
     }
     // write completed, donot focus write event.
     if (wev->active) {
          ngx_del_event(wev, NGX_WRITE_EVENT, 0);
     }
发送S0S1完毕,还是要收C2.等C0C1C2和S0S1S2都处理完毕,则进入ngx_rtmp_handshake_done,调用ngx_rtmp_cycle函数,进入包处理逻辑。

RTMP收包
这个应该是状态巨多的一个场景,每个包都是一个大状态。
首先把handler设置成收发的函数。
     c->read->handler =  ngx_rtmp_recv;
     c->write->handler = ngx_rtmp_send;
并先开始收数据并处理:
     ngx_rtmp_recv(c->read);
ngx_rtmp_recv的主要逻辑就是解析chunk为RTMP包,并调用处理包的函数。
ngx_rtmp_session_t* s中有个成员是ngx_rtmp_stream_t* in_streams,这个就是chunk streams。
     st = &s->in_streams[s->in_csid]; // 获取或创建一个chunk_stream,直接将数组转换为map,即预先开辟in_streams的空间。
其中:
typedef struct {
    ngx_rtmp_header_t       hdr;
    uint32_t                dtime;
    uint32_t                len;        /* current fragment length */
    uint8_t                 ext;
    ngx_chain_t            *in;
} ngx_rtmp_stream_t;
在每个ngx_rtmp_stream_t中都定义了一个chain:in。每个chain其实就是一个缓存,就是说给每个chunk_stream新建了一个可以写的buffer。
     n = c->recv(c, b->last, b->end - b->last); // 先收146字节的数据。调试时可以改为10,看如何解析。
b的初始化在ngx_rtmp_init_session,设置了in_streams里面:
     s->in_streams = ngx_pcalloc(c->pool, sizeof(ngx_rtmp_stream_t) * cscf->max_streams);
收到数据后,开始解析chunk。若只读取了10字节,那么basic_header当fmt为0时需要12字节,会在这个地方再读取:
     if (fmt == 0) {
          if (b->last - p < 4)
               continue;
    (gdb) p b->last - p
    $173 = 2
再次循环调用recv和解析:
     n = c->recv(c, b->last, b->end - b->last); // b->end - b->last=136,读取了10字节。
解析时,还是会重头开始解析一遍。除非header解析完了,才会改变pos位置:
     /* header done */
     b->pos = p; // p-b->start=12, fmt为0时的12字节basic header.
解析完的头如下:
     (gdb) p st->hdr
      $189 = {csid = 3, timestamp = 0, mlen = 161, type = 20 '\024', msid = 0}
有个地方验证了消息的最大长度,不能超过这个:cscf->max_message,默认1048576即1M,这个对大码率视频可能需要配置。
解析完头,就得看body是否足够了:
     size = b->last - b->pos; // buffer的数据,134
     fsize = h->mlen - st->len; // 消息还没有下载的长度。
这个时候,还需要更多的数据:
     if (fsize > s->in_chunk_size) {
          st->len += s->in_chunk_size;
          b->last = b->pos + s->in_chunk_size;
这样就算出了还需要收多少数据:
     (gdb) p b->end-b->last
      $198 = 6
然后会接着收,一直收完为止。

RTMP处理包
ngx_rtmp_recv收到一个包后,调用ngx_rtmp_receive_message处理,这个函数根据消息的类型来找到对应的handler:
      evhs = &cmcf->events[h->type];
     evh = evhs->elts;
     (*evh)(s, h, in)
消息处理的钩子函数的初始化是在ngx_rtmp_init_event_handlers,譬如AMF0的消息处理在:
    static size_t               amf_events[] = {
        NGX_RTMP_MSG_AMF_CMD,
        NGX_RTMP_MSG_AMF_META,
        NGX_RTMP_MSG_AMF_SHARED,
        NGX_RTMP_MSG_AMF3_CMD,
        NGX_RTMP_MSG_AMF3_META,
        NGX_RTMP_MSG_AMF3_SHARED
    };
    /* init amf events */
    for(n = 0; n < sizeof(amf_events) / sizeof(amf_events[0]); ++n) {
        eh = ngx_array_push(&cmcf->events[amf_events[n]]);
        *eh = ngx_rtmp_amf_message_handler;
    }
在amf的处理函数中,还得解析body内容后再调用其他钩子,来处理特定的amf0函数:
     ph = ch->elts;
     (*ph)(s, h, in) // ngx_rtmp_cmd_connect_init
也就是说,这个处理实际上是最难的,虽然一个消息能被一个处理函数处理,可是这个函数不知道很多状态信息。
不过nginx-rtmp这样还是处理的很漂亮,非常Nice。
其实同步的逻辑是这样写:
          MessagePacket* packet = NULL;
          if((ret = ctx_core->rtmp->RecvMessage(&packet)) != ErrorCode::Success){
               return ret;
          }
          if(packet is play){
               return process_play();
          }
          if(packet is publish){
               return process_publish();
          }
纯异步的方式是超级复杂,特别是加上了回源pull和push两种方式后。
能简化纯异步的技术有:
1. 将收包和解析处理分开,确认消息收到了才开始解析。
2. 异步的ATM模型,读写分开,读完才写,写完才读。
3. 处理时使用handler,譬如handshake有handler,amf0有handler,amf0-connect有handler。
同步方式是要简单很多。

Edge-relay-pull模式
nginx-rtmp的边缘叫做relay,即中继模式。有pull和push,即上行推流和下行播放。
实际上FMS是不区分这两个的,中继时只需要指定上游服务器地址即可。
收到请求前的调用:
ngx_rtmp_relay_create_app_conf,初始化app的配置。
ngx_rtmp_relay_push_pull,解析pull的命令和参数。
ngx_rtmp_relay_merge_app_conf
ngx_rtmp_relay_postconfiguration
ngx_rtmp_relay_init_process
连接上游的调用:
ngx_rtmp_relay_pull
ngx_rtmp_relay_create_local_ctx
ngx_rtmp_relay_create_remote_ctx
ngx_rtmp_relay_create_connection
ngx_event_connect_peer(堆栈如下)
#0  ngx_event_connect_peer (pc=0xa53ed8) at src/event/ngx_event_connect.c:25
#1  0x00000000004cb815 in ngx_rtmp_relay_create_connection (cctx=0x7fffffffdd60, name=0x7fffffffde80, target=0xa4fef0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_relay_module.c:468
#2  0x00000000004cba2a in ngx_rtmp_relay_create_remote_ctx (s=0xa665b0, name=0x7fffffffde80, target=0xa4fef0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_relay_module.c:527
#3  0x00000000004cbce3 in ngx_rtmp_relay_create (s=0xa665b0, name=0x7fffffffde80, target=0xa4fef0, create_publish_ctx=0x4cb9d5 , create_play_ctx=0x4cba2c )
    at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_relay_module.c:607
#4  0x00000000004cbde9 in ngx_rtmp_relay_pull (s=0xa665b0, name=0x7fffffffde80, target=0xa4fef0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_relay_module.c:630
#5  0x00000000004cc226 in ngx_rtmp_relay_play (s=0xa665b0, v=0x719da0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_relay_module.c:738
#6  0x00000000004d0df5 in ngx_rtmp_enotify_play (s=0xa665b0, v=0x719da0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_enotify_module.c:412
#7  0x00000000004d4045 in ngx_rtmp_notify_play (s=0xa665b0, v=0x719da0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_notify_module.c:1407
#8  0x00000000004d5b6d in ngx_rtmp_log_play (s=0xa665b0, v=0x719da0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_log_module.c:844
#9  0x00000000004b8f7c in ngx_rtmp_cmd_play_init (s=0xa665b0, h=0xa50dc0, in=0xa51cc0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_cmd_module.c:569
#10 0x00000000004b6d2b in ngx_rtmp_amf_message_handler (s=0xa665b0, h=0xa50dc0, in=0xa51cc0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_receive.c:436
#11 0x00000000004b28f3 in ngx_rtmp_receive_message (s=0xa665b0, h=0xa50dc0, in=0xa51cc0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handler.c:791
#12 0x00000000004b1d19 in ngx_rtmp_recv (rev=0xa7b440) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handler.c:456
#13 0x0000000000435d26 in ngx_epoll_process_events (cycle=0xa4cca0, timer=59762, flags=1) at src/event/modules/ngx_epoll_module.c:683
#14 0x0000000000428f02 in ngx_process_events_and_timers (cycle=0xa4cca0) at src/event/ngx_event.c:249
#15 0x0000000000433181 in ngx_single_process_cycle (cycle=0xa4cca0) at src/os/unix/ngx_process_cycle.c:315
#16 0x00000000004064c8 in main (argc=1, argv=0x7fffffffe5d8) at src/core/nginx.c:409
连接后,进行握手:
     ngx_rtmp_relay_create_connection
     ngx_event_connect_peer
     ngx_rtmp_init_session
     ngx_rtmp_client_handshake
握手完成时,回调relay的函数:
     ngx_epoll_process_events
     ngx_rtmp_handshake_recv
     ngx_rtmp_handshake_recv
     ngx_rtmp_handshake_send
     ngx_rtmp_handshake_done
     ngx_rtmp_fire_event
     ngx_rtmp_relay_handshake_done
     ngx_rtmp_relay_send_connect
正常的握手是没有回调的,就进入了ngx_rtmp_cycle,相当于relay在这个地方进行了hook:
ngx_rtmp_handshake_done(ngx_rtmp_session_t *s)
     ngx_rtmp_fire_event(s, NGX_RTMP_HANDSHAKE_DONE)
     ngx_rtmp_cycle(s);

异步发送多个包
回源连接connect时,连续发送了几个包,对于异步的socket,如何做到的呢?
ngx_rtmp_relay_send_connect
    return ngx_rtmp_send_chunk_size(s, cscf->chunk_size) != NGX_OK
        || ngx_rtmp_send_ack_size(s, cscf->ack_window) != NGX_OK
        || ngx_rtmp_send_amf(s, &h, out_elts,
            sizeof(out_elts) / sizeof(out_elts[0])) != NGX_OK
        ? NGX_ERROR
        : NGX_OK;
分析一个:ngx_rtmp_send_chunk_size
     ngx_rtmp_relay_send_connect
     ngx_rtmp_send_chunk_size
     ngx_rtmp_send_shared_packet
     ngx_rtmp_send_message
     ngx_rtmp_send
这个函数是先将包写到buffer:
ngx_int_t
ngx_rtmp_send_chunk_size(ngx_rtmp_session_t *s, uint32_t chunk_size)
{
    return ngx_rtmp_send_shared_packet(s,
           ngx_rtmp_create_chunk_size(s, chunk_size));
}
ngx_chain_t *
ngx_rtmp_create_chunk_size(ngx_rtmp_session_t *s, uint32_t chunk_size) 
其中,ngx_rtmp_create_chunk_size就是将包写到ngx_chain_t*,调用ngx_rtmp_prepare_message。
发送多包的逻辑是:
     if (!s->connection->write->active) {
          ngx_rtmp_send(s->connection->write);
     }
其中,ngx_rtmp_send就是一个没有返回值的函数,它主要是启动ATM到写模式,若写不完,在可写时会自动回调这个函数。
所以发送多包,实际上就是把包发送到ngx_rtmp_send(ngx_event_t *wev)的wev的chain里面,相当于缓冲区,它会保证将它发送完。
至于ngx_rtmp_send_message,根本就不会处理这个发送错误,它打交道的是缓冲区。
不过这样比起同步来,也足够麻烦了。
简化的地方:将发送和组包分离,组包到chain,可以将多个包进入队列,发送只负责发就好了。
同样,发送成功后,需要调用特殊的回调函数。
譬如处理amf的_result消息时:
ngx_rtmp_relay_postconfiguration
    ch = ngx_array_push(&cmcf->amf);
    ngx_str_set(&ch->name, "_result");
    ch->handler = ngx_rtmp_relay_on_result;
这样可以回调:
     ngx_rtmp_recv
     ngx_rtmp_receive_message
     ngx_rtmp_amf_message_handler
     ngx_rtmp_relay_on_result
     ngx_rtmp_relay_send_create_stream
整个异步的状态,无处不在。

边缘数据
边缘处理数据包的调用是:
     ngx_epoll_process_events
     ngx_rtmp_recv
     ngx_rtmp_receive_message
     ngx_rtmp_codec_av
回调是在ngx_rtmp_codec_postconfiguration中设置:
     h = ngx_array_push(&cmcf->events[NGX_RTMP_MSG_AUDIO]);
     *h = ngx_rtmp_codec_av;
     h = ngx_array_push(&cmcf->events[NGX_RTMP_MSG_VIDEO]);
     *h = ngx_rtmp_codec_av;
其中,回源连接的ngx_rtmp_receive_message会调用的handler包括:
     ngx_rtmp_codec_av //解码av。
     ngx_rtmp_live_av // 转发给所有客户端
ngx_rtmp_live_av的调用是:
#0  ngx_rtmp_send (wev=0xa95450) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handler.c:492
#1  0x00000000004b283f in ngx_rtmp_send_message (s=0xa665b0, out=0xab33e4, priority=0) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handler.c:736
#2  0x00000000004bef33 in ngx_rtmp_live_av (s=0xa53f88, h=0xaaf4a0, in=0xab1400) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_live_module.c:957
#3  0x00000000004b28f3 in ngx_rtmp_receive_message (s=0xa53f88, h=0xaaf4a0, in=0xab1400) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handler.c:791
#4  0x00000000004b1d19 in ngx_rtmp_recv (rev=0xa7b4a8) at /home/winlin/nginx-rtmp-module-1.0.4/ngx_rtmp_handler.c:456
#5  0x0000000000435d26 in ngx_epoll_process_events (cycle=0xa4cca0, timer=49151, flags=1) at src/event/modules/ngx_epoll_module.c:683
#6  0x0000000000428f02 in ngx_process_events_and_timers (cycle=0xa4cca0) at src/event/ngx_event.c:249
#7  0x0000000000433181 in ngx_single_process_cycle (cycle=0xa4cca0) at src/os/unix/ngx_process_cycle.c:315
#8  0x00000000004064c8 in main (argc=1, argv=0x7fffffffe5d8) at src/core/nginx.c:409
其中ngx_rtmp_live_av,也是调用ngx_rtmp_send_message,发送到缓冲区,然后发起发送请求而已,不必等到所有数据都发出去了。
     ngx_rtmp_live_av
     /* broadcast to all subscribers */
是在live模块中实现的这个转发,即subscribe模式。
也就是说,这个回源连接收到数据后,同时转发给了其他socket(准确讲是转发给了各个客户端的chain,然后异步发送)。

阅读(1823) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~