3.1.      Introduction

The ultimate goal of the design process is to produce a suitable design for the ISC system that satisfies the system requirements. This chapter covers the design procedure for the ISC system, including its subsystems.

 3.2.      General Architecture

The Interactive Secure Communication (ISC) system is a Java client/server distributed application that provides clients with various means of communication. The application is based on Client/Server Model, Fundamental Multimedia Data Processing (FMDPM), Transport Control Protocol/Internet Protocol (TCP/IP), and Real-Time Transport Protocol (RTP). The general overview of the system architecture is shown below in figure 3.1. 

Figure 3.1: ISC System architecture.

 The application consists of two primary modules: a server-side application and a client-side application. The server application enables connected clients to exchange messages and files and to establish voice conference sessions. The communication architecture between the system modules is illustrated in figure 3.2.

Figure 3.2: General communication architecture of the system. 

3.3.      ISC Subsystems

The ISC system consists of three major subsystems: (1) ISC Message Exchange Subsystem, (2) ISC File Transfer Subsystem, and (3) ISC Voice Conferencing Subsystem. Each of these subsystems provides specific service(s) for connected clients.

 3.3.1.      ISC Message Exchange Subsystem

Figure 3.3: ISC System architecture.

The message exchange subsystem is developed based on the Client/Server Model and the TCP/IP protocol to provide various services for connected clients, as illustrated above in figure 3.3. It is considered as the main subsystem due to the following: 

It is launched automatically once a client tries to connect to the ISC Server, since it is responsible for managing the startup connection; setting up a communication channel between client’s application and the ISC Server, as well as, transferring client’s details (screen name and passcode) to the server in order to complete the authentication process.

Other subsystems can only be launched with the help of the ISC Message Exchange Subsystem. This will be explained in more details later on.

  The services provided by this subsystem are as follows: 

3.3.1.1.      ISC Command Transfer

The ISC system defines a set of commands that are used to start, manage, and terminate communication sessions. These commands are encapsulated into Java objects before they are transferred from the client application to the ISC Server and vice-versa through the ISC Message Exchange Subsystem.  

3.3.1.2.      Start-up Connection and Sign on Process

Once a client wishes to connect to the ISC Server, a communication channel is required to enable client and server applications to exchange messages between each other, in order to complete the sign on process. Once the sign on process is successfully completed, the client can gain access to the ISC services. Setting up the communication channel and transferring the required information between a client and the ISC Server in order to complete the sign on process is called the startup connection.

Furthermore, when a client attempts to connect to the ISC Server, a communication channel, which is managed by the ISC Message Exchange Subsystem, is established between the two applications. The subsystem is then responsible for transferring client’s details that includes client’s screen name and a matching passcode, which are entered by the client, to the server. On the other hand, the latter receives client’s details and verifies them. Once the verification process is completed, either an acceptance or a rejection command is sent back to the client, depending on the result of the verification process; i.e. an acceptance command is only sent when the verification process succeeds, otherwise, a rejection command  is transmitted, instead. This process is illustrated in the startup connection flowchart below, figure 3.4. 

Figure 3.4: Connection startup flowchart.

The flowchart illustrated above, figure 3.4, defines how the startup connection between a client and the ISC Server is carried out in order to complete the sign-on process, which leads the client to either gain access to the ISC services or get disconnected from the server. However, the sign on process can be looked at two different views: the server-side application view and the client-side application view.

3.3.1.2.1.      How the sign on process is carried out by the ISC Server?

As soon as the communication channel is established between client and server applications, the server tries to access the ‘registered clients database’, which holds clients details. Then, the sign on process halts until it receives clients details (screen name and passcode). Once they are received, the first record in the database is read and verified with the client’s details. The verification process may lead to either of the following:

o       If the verification process is not successful, the server checks if the database contains anymore records, which leads to a further breakdown:

1.      The database contains more records, and therefore, the server reads the next record to verify client’s details again. 

2.      The database does not contain anymore records. Consequently, the server transmits the ISC ‘rejection’ command to the client and the communication channel is closed.

o       If the verification process succeeds, the server checks if the client has already signed on. In this case, either of the following might occur:

1.      If the server senses that the client is using a screen name that has already been signed on by someone, the server sends the ‘already signed on’ command to the client and the communication channel is closed.

2.      If the screen name is not on the ‘online users list’, the server registers client’s details (including their screen name and communication details) with the ‘online users list’ and transmits the ‘signed on’ command, and therefore, the client gains access to the ISC services.

Hence, the process keeps on looping until either of the following ISC commands is sent to the client:

•  The ‘rejection’ command indicates that the client is using an invalid screen name. Therefore, the communication channel between the two applications is closed.

• The ‘already signed on’ command leads to close the communication channel between the two applications. This command is sent to the client if he/she is using a screen name that is being used by another client.

• The ‘signed on’ command authorizes the client to access the ISC services, in the case of a successfully sign on process.

 This process is illustrated in the flowchart below, figure 3.5. 

Figure 3.5: Sign-on process flowchart – server side.

3.3.1.2.2.      How does the client application collaborate in completing the sign-on process?

On the other side of the application, once the client enters his/her details (screen name and passcode), the application tries to set up a communication channel with the server. As soon as the connection is established, client’s details are handled over to the server to perform the verification process. The client application will halt waiting for the server’s response in the form of an ISC command, as mentioned earlier. When the ISC command is received, the application checks the type of command it has received. Consequently, the client will be notified with the result of the sign on process that was carried out by the ISC Server. In essence, client application will load the communication panel preparing for proving the client with different means of communication in the case of a successful sign on process, otherwise, the communication channel will be closed and the client will be notified of the reason. The flowchart below, figure 3.6, illustrates this process. 

Figure 3.6: Sign-on process flowchart – client side.

 3.3.1.3.      Message Exchange

One of the ISC services that are provided through the ISC Server is enabling connected clients to exchange messages amongst each other. Once a client successfully signs on the system, a public communication session is established where the client can broadcast his/her message to all online clients. In addition, clients can also establish private sessions where two clients can talk to each other privately. Thus, clients can send messages to each other that can be classified into two types: public messages and private messages.

3.3.1.3.1.      Public Messages

As mentioned earlier, the public communication session, which is launched once a client successfully signs on, is where clients can broadcast their messages to all online clients. These messages are called public messages. Broadcasting public messages is carried out by both of the system modules; the client and server applications.

 3.3.1.3.1.1.      How does the ISC Server broadcast public messages?

Once a clients signs on the system, the ISC Server registers client’s details, including their connection details, with the ‘online users list’, as mentioned earlier. Following the registration process, the server authorizes the client to access the ISC services as it keeps listing to the communication channel waiting to serve client’s messages and commands. Once the server receives a public message from a client, it performs a broadcast operation on the message in order to reach all online clients, including the sender. This operation is carried out with the help of the ‘online users list’, as shown in the flowchart below, figure 3.7. 

Figure 3.7: Broadcast operation – server side.

 From the figure 3.7 above, once a public message reaches the ISC Server, the latter performs the broadcast operation that will send this message to all online clients. This is achieved by looping through the ‘online users list’ in order to get each connected client’s communication details and send the message though that communication channel. Once the server reaches the end of the list, it ends the operation. It is worth mentioning that the broadcast operation will at least send the public message to one client, who is the sender of this message. 

3.3.1.3.1.2.      How does the ISC client application collaborate in broadcasting public messages?

On the other hand, once the client application receives a public message, it delivers the message to the public communication session where it will be shown. In addition, client’s public messages are delivered to the ISC Server though the client application for broadcasting. 

3.3.1.3.2.      Private Messages

Connected clients can also establish private communication sessions amongst each other where they can talk in private. This is achieved by using another type of messages that are only transmitted to those who are sharing a private session. These messages are called private messages. 

3.3.1.3.2.1.      How does the ISC Server deal with private messages?

After a client signs on the system, he/she is also able to communicate with one other client in a private session and no other client can join in. Once the ISC Server receives a private message from a client, it deals with the message in a different mechanism from that of a public message, to ensure that the message is only delivered to the appropriate parties of the private session. This mechanism is illustrated in the flowchart below, figure 3.8. 

Figure 3.8: Transmitting a private message – server side.

From figure 3.8 above, as soon as a private message reaches the server, the server attempts to deliver the message to both parties of the private session. This is achieved by searching for the two parties in the ‘online users list’ to get hold of each one’s communication channel that will be used for transmitting the message. The two parties screen names are included in the private message that was received by the server.

 3.3.1.3.2.2.      How does the ISC client application manage private messages?

The ISC client application is responsible for transmitting client’s private message, which is captured from a private communication session, to the ISC Server after initializing the message as private message and including the two parties screen names. This process is illustrated in figure 3.9 below.  

Figure 3.9: Transmitting a private message – client side.

Figure 3.10: Receiving a private message – client side.

 It is also responsible for receiving private messages from the server and delivering them to the appropriate private communication session, where it is displayed. This operation is more complicated than just sending a private message and it is carried out as shown in figure 3.10 above.

<<   Page  1  2   >>