Load balancing System - IRIS App:互動式2.0手機廣播電台應用程式

Load balancing is a network method to distribute the network loading across multiple computers. Using lots of computers to work balancing that avoid overloading, and increase the system more reliable. Like Cloud computing, popular web site, FTP systems, DNS servers, it is impossible to handle all the users with a super power server. The system probably spread the services by functional or distribute the users by location. Figure 6 depicts a load balancing system with a primary server.

Figure 6 The load balancing system.

According to Figure 6, only primary server connected with the Internet, Load balancer and Server A, B, C and D are behind the primary server. The users ask the primary server to help, and then the primary spread the request to the dedicated server .The user even not to connect with internal server directly, the dedicated send reports of request to the primary. Then primary return the feedback to uses.

In this case, we implement a few servers into a simple load balancing system to distribute our music streaming loading, and also handle the NAT problems in our IRIS system.

CHAPTER 3 Load balancing IRIS 3.1

IRIS Architecture

Figure 7-1 A load balancing IRIS architecture

Figure 7-1 depicts a load balancing IRIS architecture. We construct four components in IRIS.

IRIS architecture:

1. DJ (Disc jockey): DJ is an anchorman and the main content provider. The DJ produced the talk show in IRIS system, which could play the music and talk about the music or anything they want to say. Also, if someone wants to use call-in service, The DJ has the ability to accept or reject.

2. IRIS Server: it is a primary and dedicated server. It manages the DJ and Audience in system, and provides the advertisement and relay message to audience. Every user should register to the IRIS server before they become a DJ or audience.

3. Secondary Server: the Secondary server would help the IRIS server to work load balancing. When IRIS server is in a heavy load, it would distribute audience to secondary Server. Secondary Server handles the audience being sent from the IRIS server, and then response all request from the audiences.

4. Audience: the general audiences. They could decide what music they want to listen, and be callers by using the call-in service to talk interactively with DJ. Or they also could choose to be DJ.

Figure 7-2 IRIS architecture with Firewall

Figure 7-2 depicts the architecture with Firewall. Every audiences and DJ connect with Wi-Fi AP and firewall. The firewall is usually contained in Wi-Fi AP because Wi-Fi AP constructed by private network. The network connection links transfer streaming from Wi-Fi AP through the Internet to IRIS Server.

Initially DJ joined into system, and then sent the audio and music streaming to IRIS server, IRIS server helps the DJ to relay his streaming into the channel by sending the streaming to every audience who is listening to the channel right away. Their two are the most import roles in IRIS.

Every audience could choose to be a DJ. That is a big difference with the other radio applications on Android system or iOS. Figure 8 depicts a simple construction of IRIS. DJ transfers his music streaming to IRIS Server, and IRIS relay the streaming to an audience and

Secondary Server. Secondary serves the audience which connected with.

Figure 8 Simple construction of IRIS

3.2 IRIS Construction

3.2.1 DJ Join

When an audience chooses to became a DJ, it would send a DJ request connection to the IRIS Server. Figure 9 depicts the flowchart of the DJ join.

Figure 9 Flowchart of DJ Join

After IRIS Server got a DJ request connection, it executes a channel selection. The selection is checking all the channels if there is an empty channel. That would be a noise if there were two or more DJ playing the music in the same channel. So before we investigate solutions like communication with two DJ or something solving the noise problem, in the IRIS now we observe a principle that must only an anchorman in a channel. If there is no empty channel in IRIS, the IRIS Server would send a reject answer to the DJ. If there is an empty channel, IRIS server would gets the DJ into the empty channel and then lock it avoiding the other DJ get in. And then Server keeps receiving the streaming from DJ. After receiving a buffer of music streaming, Server would search to relay list to find out how many audiences are in this channel, and relay the streaming to all the audience. And DJ is no need to worry about the relay.

The server would maintain relay list when relay the streaming. If the server finds out that the relay link to an audience was dead, which means the audience is leaving the channel no matter how for any reasons. Server would remove the link from the relay list. That is okay for server handling that the audience leaves.

3.2.2 Audience Join

When a user gets into IRIS, we define that the user will be an audience first. No matter the user chose the channel or not. The audience could select the channels we provided or doing nothing that just stay in the IRIS. When an audience selected the channel, it sends an Audience request connection to IRIS Server. Figure 10 represents the flowchart of Audience Join.

Figure 10 Flowchart of Audience Join

After receiving an audience request connection, the Server would check the channel

up-bound. The channel up-bound was setting to avoid server over load. Because the audiences increase were also increased the server relay loading, so we deploy an simple load balancing solution, and we will discuss it later.

If the channel up-bound is not reached, the server would put the audience connection link into relay list and return an okay message to the audience. If the channel up-bound is reached, it would check if there is Secondary server which is working for load balancing. If there is no more Secondary Server to handle with redundant audiences, the IRIS Server would send a reject message to the audience. The audience knows that the channel is busy right away; it would select the same channel later or choose the other channel that is not busy.

If there is a Secondary Server could accept redundant audience, the server would give the audience which chose the channel the Secondary Server information include the IP address and listening port. After receiving the new IP address and port, the audience would connect to the Secondary Server. And the Secondary Server runs the same algorithm which the Figure 10 described.

3.2.3 Call-in

It is unique utilizaion in a radio system over smart phone like we said before. Figure 11 describes the flowchart of Call-in service.

Figure 11 Flowchart of Call-in service

When audience listened the talk show that produced from DJ, there is a chance that making a Call-in service. If IRIS server got a Call-in request, it would find which DJ is in the channel that the call-in audience selected and search the DJ connection link from DJ list. Then it sends a request to DJ querying the Call-in. If DJ denied the request, then Server response the audience that DJ reject his request. If DJ accepted the Call-in, the audience would be the caller and the IRIS Server would help with relaying their streaming to each other. The channel would start interactive communication between the HOST and the caller, which is VoIP service. And the other audiences are still in this channel, they would hear the communication in the radio.

3.2.4 Load Balancing Server Relay

When more and more audiences got into the same channel, the IRIS server increases the same

level of work loading. Because IRIS is developed based on TURN algorithm and TURN is the Client-Server architecture. The throughput bottleneck would appear on IRIS Server. In the initial stage of IRIS, we design a simple way of load balancing as the solution with the bottleneck. That answer is that we deploy some Secondary Servers behind the IRIS Server.

When IRIS Server is going to or has been over load, it would ask Secondary Servers for help.

The IRIS Server would pass the audience to Secondary Server if the Secondary Server has redundant utilities.

Figure 12 Flowchart of Secondary Server service

Figure 12 depicts the flowchart after Secondary Server adopted the audience. First server gets the order from audience; server will check whether there is a streaming which the audience wants. If the answer is yes, which means there is another audience that listened the same channel on Secondary Server. It will relay the streaming right away. If not, the Secondary Server would ask IRIS Server for the streaming that it need, and then relay the

streaming. So if there are N audiences that were listening to the same channel on Secondary Server, the IRIS Server would reduce (N-1) relay connections.

CHAPTER 4 Implementation

4.1 Reality

Figure 13 The implement devices

Table 3 Experimental Setup

Figure 13 shows the devices we implemented IRIS on. There are HTC Desire and SAMSUNG Galaxy S i9000. Table 3 describes the environment and experimental setup. The environment is based on Android system and the version 2.2 (API Level 8). The Android phone should be the version 2.2 or later to run IRIS.

When we developed the IRIS that was some subjects should be concerned. First, Android does not support the audio library which is in java before. The audio library could help us handling the music format. In real time system we must transform the music format into streaming instead of commonly music format which is like mp3. So we must to develop the transformation by ourselves. But there existed the second problem on smart phone; the CPU rate is usually lower than PC. And not only CPU rate but also cache memory and security. It must be developed careful to avoid that too many threads ran at the same time over smart phone and thread occupied too much CPU time especially the transformation thread. The third subject is NAT Problem that we have been discussed above this chapter.

4.2 Traversal Using Relay NAT

The NAT solution we adopted is Traversal Using Relay NAT (TURN). Figure 14 depicts a simple concept of TURN and why can’t we implement the P2P connections

When DJ has produced the talk show, it is better that audiences connect directly with the DJ

by P2P connection. But there exists a NAT problem. When Audience A and B tried to connect directly with DJ. The NAT device is above the DJ and how does it quit the connection is depend on the NAT type. In commonly the directly connection could not be initial, so instead of the traditional way we developed DJ to send his talk show streaming to IRIS Server. The Audience A connected with IRIS Server instead with the DJ. Of course there exists the same NAT problem between IRIS Server and DJ. IRIS Server could start the connection with DJ only if DJ has been sent a packet to IRIS server before. In case of that, in reality we suppose that DJ is necessary registering his information to IRIS Server before DJ start its talk show.

Therefore it solves the initial problem of TURN and also helps us to manage how many DJ is active in IRIS

Figure 14 NAT traversal

4.3 Load Balancing System

4.3.1 IRIS without Load Balancing

Figure 15 presents IRIS without Load Balancing. There are four audiences A, B, C and D listening to the same DJ talk show and only one IRIS Server served. If audiences keep increased, the IRIS Server would overload in the expectable time. There are five connections work on IRIS server that one connection is receiving the DJ Streaming and the remained four connections are relaying the Streaming. It means that IRIS Server needs to relay a streaming four times to four different audiences.

Figure 15 IRIS without Load Balancing

4.3.2 Secondary Server Load Balancing

Figure 16 presents that IRIS works load balancing with Secondary Server. It has deployed

two the secondary servers. Comparisons with Figure 15, there are seven connections in IRIS that are more than Figure 15, but each server (an IRIS server and two Secondary servers) only maintain three connections. The upper Secondary Server in Figure 16 maintains two relay link for Audience A and B. The lower one maintains two remained Audiences. The IRIS Server just relay a streaming twice instead four times. This way reduces the network connections that focus on IRIS Server and balances the loading.

Figure 16 IRIS works load balancing with Secondary Server .

If Secondary Server could communicate with other servers, that could reduce one more connection on IRIS Server as long as the lower Secondary Server asks the upper Secondary Server in Figure 16 for the same streaming instead asking IRIS Server. It can be achieved by

developing communication algorithm between IRIS Server and Secondary Server. But for now, we do not develop a complex algorithm for load balancing. The Secondary Server follow a simple principle that when it got a audience request, it would accepted the request if it has redundant utilities or passed the request to other server until there is no more Secondary Server could be passed, and the final Secondary Server rejects the request finally.

4.3.3 Three DJ in IRIS

The IRIS provides three DJ channels now; it means that allow three DJ talk shows at most in the same time. In order to make it convenient for management, the IRIS Server would concentrate all the DJ connections for the purpose of the call-in service in the future. In this way of centralization development, IRIS take care of all the DJ connections, and does not need to communication with Secondary Servers to know about how many DJ are on the air in IRIS. The Secondary Servers are only responsible for that audiences were passed from IRIS Server and relay the streaming what audiences want. Figure 17 depicts three DJ are on the air in IRIS. It is similar with one DJ, three DJ connections all connected with the IRIS Server.

IRIS Server connected with an audience and two Secondary Servers. In this case, if there is a DJ that wants to join, it would be rejected because all three channels had been taken. If there is an audience that wants to join, it would depend on the two Secondary Servers whether enough utilization had or not.

Figure 17 Three DJ are on the air in IRIS.

4.3.4 Call-in In IRIS

Because the DJ connections has been concentrated on IRIS Server, if there is an audience want to make a call-in service, this audience will send a call-in request to IRIS Server directly not through Secondary Server. Then Server would execute this request by the algorithm that Figure 11 represented. Figure 18 depicts the architecture after an audience made a call-in to DJ. When DJ accepted the call-in, the IRIS Server creates a new thread for Caller. This thread relays the streaming that sends form Caller to DJ. But Caller still receives the streaming of DJ that relay from the Secondary Server.

Figure 18 A audience make a call-in to DJ.

In fact, there were two different ways that Caller could receive streaming from. First is received from IRIS Server directly, it would cause IRIS Server additional network load.

Second is received from Secondary Server after IRIS Server sent it to Secondary Server.

4.4 User Interface

Figure 19 Flow chart of IRIS

Figure 19 depicts our IRIS program flowchart. First picture is login interface. Second picture is Audience interface; we present its function of buttons in section 4.4.1. The third picture present the DJ interface, we would explain it in section 4.4.2.

As the Figure 20 presents, it is the first frame of IRIS. But it is just a login interface; users don’t enter the system yet. In this situation, user should input their account to login, although we do not authenticate the user accounts yet. On the IRIS server screen, we could find out how many users were login into IRIS and saw their account name. Every DJ, Audiences and Caller connection would cause some input of information on screen.

Figure 20 Login interface

4.4.1 Audience

As long as users login into IRIS, all users become audience in Audience interface .

Figure 21 depicts IRIS Audience interface on Samsung Galaxy S i9000.There provides three channels which are Channel 1, Channel 2 and Test_channel to select. When audiences selected Channel 1 or Channel2, the 59connection thread in IRIS would send a audience request to IRIS server. After Server excuted Audience Join algorithm and accecpted the Audience request, initially the music streaming play button would turn on and play streaming automatically, and then Audience started enjoying the talk show. And now Test_channel will

not accept any DJ to get in. In fact, two channels have been aleady enough to deal with the quanity of smart phone devices we have. The third channel “Test_channel” is not opened temporaily so that make expanding or other broadcast in the future.

Figure 21 Audience interface

The next two buttons are “Play” and “Stop”. If audience listened to talk show and wanted to stop for a while, the button “Stop”could be clicked to stop playing streaming from talk show. It is not stopped or diconnected with Server,the connection was keeping connected.

Just the Audience chose to not to listen to the music, the Server that Audience connected still transmited the streaming to that. And if audience wants to restore listening to the talk show, clicking the “Play” button. It would return back to the “Play” situation that restart the IRIS

talk show in real time.

The remained three buttons are Call-in, Quit and DJ. When Call-in button was clicked, it would excute the algorithm of the Call-in service that Figure 11 described.After DJ accepted the call-in request, it initially started audio communication which applied for VoIP automatically. When an Audience became to a Caller, the “Play ” and “Stop” buttons still work like being an Audience before, “Play” button refers to start or return back to play, “Stop”

button refers to stop listening to the audio streaming recording from DJ.

The “Quit” button is functional for disconnecting all the network connections. It means if an audience does not want to listen to talk show anymore or a Caller wants to hang up the call-in, they could click the “Quit” button. It would stop receiving streaming from Server and stop all the network connections. And the point is that “Quit” button only disconnected all network connections, but not leaving the IRIS, so that they are still staying the Audience

在文檔中 IRIS App:互動式2.0手機廣播電台應用程式 - 政大學術集成 (頁 23-0)