Boost C++ Architectural Design Pattern for Audio Streaming Multi-clients Server

[bbspeterlee]

Boost C++ Architectural Design Pattern for an Audio-focused Streaming RTMP Multi-clients Server

Hi all,

This is a high level question, and it's all about the architectural design pattern.

I did google a lot, but unfortunately, there is no design documents available for their implementation, and usually the implementation is very complicated, and hard to figure out what the pattern is.

Basically, my server (a reasonable commercial server) should: Requirements:

* Be able to handle 500+ clients/connection at the same time (I guess one-thread-per-connection might kill the server? context switch);
* Can handle 100+ clients/connection with audio communication simultaneously;
* One connection getting stuck/crashed should not affect the other connections;
My thoughts about the design:

* One thread per connection;
* One process per connection;
* Asynchronous connection acceptor;
* Blocking connection acceptor;
* Asynchronous incoming data receiver;
* Blocking incoming data receiver;
* Thread pool with specific number of threads for handling the connection acceptor;
* Thread pool with specific number of threads for handling the incoming data;
What combination of the above thoughts will do a great job for the requirement list I mentioned before?

Thanks. Any ideas are welcomed!

Peter

[AlanBruce]

Mark!

[lucky-lucky]

Great ....
but I say ,I can only only 顶

[bbspeterlee]

Yes, it's a very high level question, and kind of difficult to figure out :-)

[HelloDan]

If I were you, I will decouple this project to 2 or even more server processes.

first one manager daemon server, which handle user relationship, users log in and making audio call request

second, at least one audio server handle user making audio communication



a little more detail, for example, user A make a audio call to user B, the manager daemon server parse this request to check if B is online or not. if online, the manager will assign one audio server ip and port to user A and user B. both the users should connect to the audio server to start their audio communication.

while the audio server is a light weight process, only receive data and send data, it should implement a fast look up data structure to find the proper socket to send data to the destination user.

Both servers can be implemented as Asynchronous network single thread processes, such as IO completion port in windows, epoll in linux and kqueue in freeBSD.

[largep]

multithread + noblock IO, a queue and thread pool for recv and send data.one process use for login/logout.

[gunsand]

u need a high performance server framework. i recomend mudoo c++ server architecture. what u need to do is just coding your logic.