As illustrated in figure 3.10 above, a ‘private-sessions list’ is used to keep hold of each private communication session that could be established, as long as the client is online. This list helps the client application to deliver private messages, which are received from the server, to the appropriate communication session. However, private sessions are distinguished by the other party’s screen name. In more essence, once a private session is received, the client application performs a search for the appropriate communication session using the ‘private-sessions list’. The search operation is carried out by looping through the list until the other party’s screen name matches. As soon as the session is found, the received private message is delivered to the communication session, where the message will be shown.

3.1.1.1.1.1.      Establishing private communication sessions

Prior launching any private communication session, a private session request must be sent to the other party to ensure his/her interest in establishing a private session. A reply must then be sent by the other party to confirm either acceptance or denial of the private session request. The process mechanism is illustrated in figure 3.11. 

Figure 3.11: Establishing a private communication session.

From the above-illustrated process, certain steps can be noted. These involve the following: 

(1)           Client A, who is attempting to establish a private communication session with Client B, initializes a private session request assigned to Client B and transmits it to the ISC Server.

(2)            In turn, the ISC Server forwards the request to Client B.

(3)           Once Client B’s application receives the request, it responds to it by initializing a private session reply assigned to Client A. It then transmits the reply to the server. A private communication session is only launched by Client B’s application if he/she responds positively.

(4)           Finally, the ISC Server passes on Client B’s private session reply to Client A. Consequently, Client A’s application reacts to the reply and launches a private communication session with Client B only if the reply is positive. Otherwise, the application displays an appropriate decline message to Client A. 

It is worth mentioning that both of the private session request and the private session reply are ISC commands which are encapsulated into Java objects along with other details, such as the sender of the request and its destination (receiver).  

3.1.2.      ISC File Transfer Subsystem

The file transfer subsystem is developed based on the Client/Server Model using the TCP/IP protocol for communication. The major objective of the subsystem is to enable connected clients to exchange files amongst each other. The process of transferring files is mainly performed by the client application. Basic overview of the subsystem is illustrated in figure 3.12 below, where Client A is transmitting a file to Client B.

Figure 3.12: ISC File Transfer Subsystem.

Prior transferring any file between two client applications, a connection setup process must be accomplished. Hence, the following two processes are essential for clients to exchange files.

3.1.2.1.      Connection setup process

Transmitting a file from a client application to another is achieved using a private TCP/IP communication channel that is established between the two applications. Therefore, transferring files between client applications is accomplished through a one-to-one communication channel that is established prior exchanging files. The process of establishing a private communication channel between two client applications is called the connection setup process.

The connection setup process is carried out using a set of ISC commands that are transferred though the ISC Message Exchange Subsystem. Once the process is successfully performed, the ISC File Transfer Subsystem is then launched. The two client applications that are attending to exchange a certain file collaborate in performing the connection setup process. Thus, the process can be discussed under two different point of views: sender’s point of view and receiver’s point of view.

3.1.2.1.1.      Sender’s side of application

In case of an online client wishes to transmit a file to his/her peer, an ISC file transfer request is initialized and sent to the other party. The purpose of the request is to ensure other party’s interest in establishing a file transfer session. Therefore, a reply must be sent by the other party to confirm either acceptance of or denial of the file transfer request. If the other party replies positively to the request, connection details are also transmitted along with the reply. These connection details are essential for the sender to establish a communication channel with the other party, which is used for file transmission. However, if the other party replies to the request negatively, no connection is made. This mechanism is illustrated in figure 3.13.

3.1.2.1.2.      Receiver’s side of application

On the other hand, once a file transfer request reaches the receiver application, client can either accept the request or deny it. Consequently, accepting the request leads the receiver’s application to transmit an acceptance file transfer reply along with the connection details that are required to launch the file transfer process. However, rejecting the transfer request leads the receiver’s application to transmit a denial file transfer reply. Hence, the process is terminated, and therefore, no file is transferred. Figure 3.14 below illustrates this mechanism.

Figure 3.13: Connection setup – sender’s side.

Figure 3.14: Connection setup – receiver’s side.

 Consider the illustrated example below, where Client A is attempting to establish a file transfer session with Client B, see figure 3.15.

Figure 3.15: Establishing a file transfer session.

 From the above-illustrated case, certain steps can be noted. These involve the following:

(1)          Client A initializes a file transfer request assigned to Client B and transmits it to the ISC Server.

(2)           In turn, the ISC Server forwards the request to Client B.

(3)           Once Client B’s application receives the request, it responds to it by initializing a file transfer reply assigned to Client A. It then transmits the reply to the server. In case the client replies positively, connection details are sent along with the reply.

(4)           Finally, the ISC Server passes on Client B’s file transfer reply to Client A. Consequently, Client A’s application reacts to the reply and launches a file transfer session with Client B, using the connection details that are included within the reply, only if the reply is positive. Otherwise, the application displays an appropriate decline message to Client A.

It is worth mentioning that both of the file transfer request and the file transfer reply are ISC commands which are encapsulated into Java objects along with other information, such as the receiver’s connection details.  

3.1.2.2.      File transfer process

Once the file transfer session is launched, consequently a private communication channel is established, where the receiver’s application acts as a temporary server and the sender’s application acts as a client.  The direct connection between the two applications lasts until file transmission is completed. Both of the sender’s and receiver’s applications collaborate to accomplish file transmission.

 3.1.2.2.1.      Sender’s application

Once the sender’s application receives the green light to launch the file transfer session, it immediately attempts to establish a connection with its other party. The file transfer process then takes place after compressing the file. The process is illustrated in figure 3.16. 

Figure 3.16: File transmission – sender’s side.

From the above-illustrated flowchart, as soon as the communication channel is established, the sender’s application attempts to compress the file then it transmits the file details, including file name and size, that it wishes to transmit. The file is then broken down into streams of bytes that are transmitted down the communication channel in a fixed length until it reaches the end of the file. In addition, after each transmission of bytes, an ISC command is also transmitted to indicate whether there are more byes to transmit or not. Once the application reaches the end of the file, a closing connection command is issued then sent over to the receiver; consequently, the communication channel is then closed. 

3.1.2.2.2.      Receiver’s application

On the other hand, the receiver’s application starts up a server connection where it waits for its other party to establish a communication channel with it through that connection.  The file transfer process is then launched. The flowchart below illustrates this process, figure 3.17. 

Figure 3.17: File transmission – receiver’s side.

 As soon as the sender establishes a communication channel with the application, the latter halts waiting to receive file details. Once the details are received, the application starts receiving the file as streams of bytes. An ISC command is also received, which follows each transmission of a set of bytes, to indicate if there is more to receive or not. As soon as the end-of-file command is received, which is followed by a closing connection command, the communication channel as well as the server connection are closed.

 3.1.3.      ISC Voice Conferencing Subsystem

The ISC Voice Conferencing Subsystem is to be developed based on the Client/Server model and Real-Time Transfer Protocol (RTP) using Java Media Framework (JMF). The main objective of the subsystem is to provide authorised client with a real-time application that enables them to establish voice conferencing sessions amongst each other. The subsystem launches in a smellier manner as the ISC File Transfer Subsystem; the subsystem is mainly implemented on the client application. 

Figure 3.18: ISC Voice Conferencing Subsystem.

 It is essential for connected clients to accomplish a successful setup connection process before voice concerning sessions can be launched.

 3.1.3.1.      Connection setup process

Launching a voice conferencing session requires a private RTP communication channel between the two parties. Therefore, a voice conferencing session represents a one-to-one RTP communication channel that is established prior starting the session. The process of establishing the RTP channel is called the connection setup process.

 The connection setup process is carried out using a set of ISC commands that are transferred though the ISC Message Exchange Subsystem. Once the process is successfully performed, the ISC Voice Conferencing Subsystem is then launched. The two client applications that are attending to share the voice conferencing session collaborate in performing the connection setup process. Thus, the process can be discussed under two different point of views: sender’s point of view and receiver’s point of view.

 3.1.3.1.1.      Session requester’s side of application

In case of an online client wishes to share a voice conferencing session with his/her peer, an ISC voice conferencing request is initialized and sent to the other party. The purpose of the request is to ensure other party’s interest in establishing a voice conferencing session. Therefore, a reply must be sent by the other party to confirm either acceptance of or denial of the voice conferencing request. If the other party replies positively to the request, connection details are also transmitted along with the reply. These connection details are essential for the sender to establish a communication channel with the other party, which is used conferencing. However, if the other party replies to the request negatively, no connection is made. This mechanism is illustrated in figure 3.19 below. 

Figure 3.19: Connection setup – sender’s side.

3.1.3.1.2.      Other party’s side of application

On the other hand, once a voice conferencing request reaches the other party, he/she may either accept the request or deny it. Consequently, accepting the request leads the receiver’s application to transmit an acceptance voice conferencing reply along with the connection details that are required to launch the voice conferencing session. However, rejecting the conferencing request leads the receiver’s application to transmit a denial voice conferencing reply. Hence, the process is terminated, and therefore, no session is launched. Figure 3.20 below illustrates this mechanism. 

Figure 3.20: Connection setup – receiver’s side.

 3.1.3.2.      Voice conferencing

Once the voice conferencing session is launched, consequently an ISC Voice Conferencing Session is established. The direct connection between the two applications lasts until the session is terminated. The following illustrates the design of transmitting and receiving RTP.

 3.1.3.2.1.      RTP transmission

Once a voice conferencing session is loaded, the application attends to create a Processor, which is configures to output RTP-encoded data, with a DataSource to read from the client’s microphone. The output of the process is then translated into a DataSource that will be passed in along with a MediaLocator, which describes the RTP session to which the DataSource is to be transmitted. In turn the MediaLocator provides the address and port of the RTP session. In addition, clients may control the transmission by using the appropriate buttons provided.

 3.1.3.2.2.      RTP Receiver

On the other side of the communication channel, the receiver’s application will started up an RTP session by creating a SessionManager, and then, a listener is registered to listens for incoming RTP packets. Followed by initiating a session manager, the RTP session is started.

Once an RTP packet is sensed by the listener, the application attempts to receive the incoming stream. Once the stream is received, a Player is initiated for the client to play the incoming stream.

<<   Page  1  2   >>