1
0
Fork 0
mirror of https://github.com/ossrs/srs.git synced 2025-03-09 15:49:59 +00:00

update readme, multiple process and cli architecture.

This commit is contained in:
winlin 2014-03-03 16:17:20 +08:00
parent 7daf890d87
commit 7da3420997

View file

@ -239,25 +239,55 @@ Schema#2: SRS RTMP Edge server pull stream from origin (or upstream SRS
</pre> </pre>
(plan) SRS Multiple processes Architecture:<br/> (plan) SRS Multiple processes Architecture:<br/>
<pre> <pre>
+---------------------------+ +-------------------+ +-----------+
+-----+ worker process(3) | | upnode server | + client +
+----------------+ | +---------------------------+ +---------+---------+ +-----+-----+
| master process |---(2)---+ --------------+------------network-------+---------
| (1)manager | | +---------------------------+ | |
+----------------+ +-----+ worker process N | +-----------+ +----+-----------+ +----+------+
| +---------------------------+ | master +--fork->-+ back source(1) +-->-pull-+ stream(2) +
| +-----+-----+ +----------------+ +-------+---+
| +---------------------------+ +-------------------------------------fork--->-----+
+-----+ bandwidth test process(4) | | +-------------------+
+---------------------------+ +--fork->--+ bandwidth test(3) +
+-------------------+
Remark: Remark:
(1) master process: to fork processes, schedule fd(client) to the "right" (1) back source process: create by master process, get stream from
process, forward messages between processes upnode server, serve the stream process.
(2) communication: master process use unix domain socket to communicate (2) stream process: create by master process, get stream from back
with worker processes. source process, serve the client.
(3) worker process: to provide RTMP streaming service, generate HLS files. (3) bandwidth test process: create by master process, serve the
(4) bandwidth test process: for all bandwidth test request, to make the bandwidth test client.
bandwidth testing has minimal effect to streaming service Remark:
(a) This multiple processes architecture is design by wenjie, it's a
very simple and powerful multiple process architecture, for the
master no need to pass between stream process.
(b) The CLI architecture is similar to this, instead, cli process
will collect informations from all stream process, master process
only send signals to child processes.
</pre>
CLI Architecture:
<pre>
+---------+
+--+ stream1 +---------+
| +---------+ |
+--------+ | +---------+ | +-------+
| master +--fork->-+--+ streamN +---pull--+>--+ cli +
+--------+ | +---------+ | +-------+
| +-------------+ |
+--+ back source +-----+
+-------------+
Remark:
(1) master listen the global api port, for example, 33330
(2) back source and stream processes listen at private api port,
for example, 33331, 33332, 33333
(3) work processes(stream and back-source), report private api
port to master global api port.
(4) cli connect to master global api port, get all other private
api ports
(5) cli connect to each stream/back-source process to get api data,
cli analysis and summary the data, return to user.
</pre> </pre>
Bandwidth Test Workflow: Bandwidth Test Workflow:
<pre> <pre>