Creating conferencing system
In addition to peer-to-peer communication, and one-to-many streaming, VC components also include a high performance audio conference server with multiply room support (provided with Enterprise license only).
Audio conference is a multi-party communication process, where every participant can hear all other parties. Like in everyday meetings, people connected to a conference server can collaborate on a joint topics.
Each client records and sends voice stream to the server, and receives special mixed stream for playback. Since our server supports many rooms, upon successful connection client must specify the room it wants to enter by sending a special packet to the server. Each room has unique name and optional password usually provided by end-user.
On a screenshot below the client was allocated seat #1 in the room "email@example.com". Notice the "Room Name" and "Room Password" input fields.
High performance server considerations
The heavy task of audio decoding, mixing, encoding is put on the server. This way we sacrifice CPU cycles to save the bandwidth. Two important considerations must be noted therefore:
While the first issue is under your control, we control the second one. Here is what was done about it in January 2008 release of VC components.
First, our underlying IP server component was completely rewritten to adapt to the new model of operation. This model is based on I/O completion ports (IOCP) and asynchronous (overlapped) sockets operations. The advantage of this model is salability of server software, which means it can effectively put every processor (core) in use to handle a heavy load.
(NOTE. For our server to run in new mode, Windows NT Workstation 3.5 or Windows 2000 Professional or later is required).
Second, we have rewritten the mode in which our ACM codec component decodes and encodes audio data. In this new mode multiply codec components can perform data processing from one thread, reducing the amount of unnecessary context switching. Before January 2008 release 100 codec components would require 100 threads for operation. Assuming two codecs are needed per one client connection (one for decoding and one for encoding), 200 threads would be created per 100 clients, restraining previous version of server from handling large amount of clients.
One server, many rooms
In addition we have also extended our server so now it can handle several isolated rooms, still listening on one port. Rooms may be created automatically, when new client connection is accepted and non-existing room name is provided by it, or rooms may be created ahead by administrator.
On a screenshot below the room "firstname.lastname@example.org" was created by administrator and has no participants so far.
Technical details: Client
Conference client and server sources can be found in the "<VC_root>\demos\ConfRoom\" folder.
Client is implemented as the
When client receives
Please refer to client\ConfRoomCln.dpr sample for more information.
Technical details: Server
Server is implemented as the
The following global constants specifies server limits and must be assigned according to your needs for optimal performance:
The main job is done in
Note that if server was compiled with "DEBUG" symbol defined, it will send client's audio back to client, if there is only one participant in a room.
It is strongly recommended to use UDP sockets for audio streaming with conference server, as they dramatically reduce the CPU load on it. As was noted before, server sacrifices CPU to save the bandwidth.
Please note, that Windows 2000 Professional has maximum processor limit of 2 and is not aware of Hyper-Threading technology. Refer to this article for more information.
It is not recommended to run server on Windows 98/Me, unless you have small number of clients. Server will operate in old "select()" sockets mode in this case.
Precompiled binary of this sample is included in the Demos package.