Proxy Server for the Virtual Collaborative Environment

Abstract

The goal of this project is to develop a Proxy for the Unicron Server. The proxy server is meant to be located at a place which is far away from the Local Area Network which has the Central Server. The central idea which drives the design of the proxy server is minimization of the amount of traffic generated over the wide area network because of the connections that exist between the clients in the remote place and the central server.

1.0 Unicron – A Virtual Collaborative Environment

In this section we give an introduction about the Unicron Project. The Unicron project is aimed at developing an interactive virtual world of the NMSU CS department. Clients are represented by avatars. Clients can move around, see each other, communicate with each other, can transfer files between them and perform all sorts of group activities [1].

The Unicron server supports each client through TCP connections. The communication between the clients is done in a centralized manner. There are different types of communication messages,

(1)   Client sends message to the all other clients

(2)   Client sends a message to other clients in a particular group

      (3)  Server sends message to a single client in response to an event.

      (4)  Server broadcasts a message to all clients in response to an event

      (5)  Server broadcasts a message to a subset of clients. For example clients in a

             particular group or room etc. 

Since the clients do not have direct connections between them, all communication between two clients has to pass through the server. So the message types 1 and 2 also involve the server. We analyze this more thoroughly in the next section.  Section 2 gives motivation behind the proxy and talks about the kind of messages that can be optimized. Section 3 talks briefly about the network protocol between proxy and server. In section 4 we discuss about various modules in the proxy server code. In section 5 we talk about the future work and conclude. 

Figure 1.0 – Unicron Server - Client communication through Wide Area Network

2.0 Proxy Server

The Central Idea – Reducing Communication through Computation

Let’s assume that there are two clients A and B which are located in a remote campus. They are connected to the unicron server at the NMSU campus. If client A sends a message to client B, the message has to go to the server through the wide area network and the server will send the message to client B through the wide area network. Eventhough the clients which are communicating are located in the same network, message traverses an external wide area network, reaches the server, and returns to the destination traversing the same wide area network (Figure 1.0). If the network distances of the client A and B with that of the central server is not very big or if the size of the communication messages are very small, then there is not much of a gain that we can achieve by trying to optimize the overall bandwidth utilized and delay.  But on the other hand if there are frequent communication between the two clients (We will see an example of this scenario) and the size of each message is high, we can certainly achieve considerable performance improvements if try to optimize the communication overhead.

Since there is a high probability that the latter case occurs often, the existence of a proxy server at the remote campus aimed at reducing the communication overhead is justified.

Figure 2.0 – Unicron Server - Proxy - Client communication through Wide Area Network

Now that we have established the case for the development of a proxy server we get into the details. Figure 2.0 shows how the proxy server sits in between the Server and the Clients. In order to achieve its goals, the proxy server has to make intelligent routing decisions by reading the messages it receives from the client. The rest of this paper discusses about the design of the proxy server.

2.1 Initial Setup

When a client logs into the proxy server, it makes the connection for that client with the central server. Then the proxy server will send a command to the central server informing that this client is indeed connecting through the proxy. This information is helpful for the server in future. Also when a client logs out, the proxy server will issue a command to the server. The following are commands which are supported by server for synchronizing with the proxy.

(1) \newproxy "proxy name"

      Proxy will send this command when it starts up. The server will maintain a list of

      proxies which are currently running.

(2) \delproxy "proxy name"

      Proxy will send this command just before it closes. The server will remove the proxy

      from its list.

(3) \proxylogin "uid"

      Proxy will send this command when a Client has logged in.

(4) \proxylogout "uid"

      Proxy will send this command when a Client logs out.

Since all the messages that are being communicated are in the form of commands. As a first step we will figure out some ways to optimize the commands. These are the list of some commands,

(1)   \say hello – chats to the current room

(2)   \say joe hello – chats to a specific person

(3)   \move 0, 0, 0.5 – move to (x,y,z)

  We specifically concentrate on the \move command for now.

2.2 The \move command

Whenever a client moves, a “\move x,y,z” command is generated by that client and sent to the server. So normally when a client moves, it’ll generate \move commands continuously. (The number of \move commands generated for x units of displacement is yet to be computed. But they are generated at substantially high numbers for relatively small units of displacement). The server maintains a dynamic list of clients’ room information. When a client moves from one room to another, it updates that dynamic list. Also whenever the server receives the \move command from a client, it figures out which other clients need to know about this move, and then it sends the move to those clients.  

The server figures out which clients need to be informed of a “move” using some visibility rules. For example, the clients who are in the same room as the client that moved and also the clients in adjacent rooms. Basically the \move has to be sent to all the clients who are in close vicinity and the clients which can actually see that move. To get a complete idea of these visibility rules, we have to study the source code of the central server (This is to be done yet). So just to get started we have made some assumption about the visibility rules.

The idea is this: If the proxy server has the knowledge of the visibility rules and the dynamic room information of each client that has logged into it, then it can make the decision of what other clients are to be informed of the move by without having to contact the central server. Now that the central server knows the proxy will take care of the \move command for the clients which are logged into it, it will not has to send the \move if the recipients of the \move are supported by the proxy. So by having some redundant information and doing some computation at the proxy, we are able to achieve optimize the performance.

The thing that the proxy has to have as stated above is the room information and visibility rules. We will see how the proxy gets these.

 (1) Room Information of the Clients:

We have a graph structure of the rooms x, y, z coordinates and their connectivities. This is fairly static. The proxy stores these information in a Hash Table data structure so that searching for a particular room is done fast.

The proxy server being able to read the clients’ messages enable it to get the location information of the clients without having to get them from the Server. When a client logs in, the server sends out an \avatar command to that client, that has the x,y,z coordinates of its location. Also when a client moves from one room to another it sends a “\nodechange new_room old_room” command to the server. So with these commands the proxy will know the room information of all the clients that are logged into it.

(2) Visibility rules for the \move command

The visibility rules that the proxy follows is,

(i) Send the \move to all other clients which are in the same room.

(ii) Send the \move to all clients which are in adjacent rooms.

(Adjacent rooms are the rooms which share an opening or a door)

Currently the visibility rules are not completely in synchronization with the server at the moment. To make it fully synchronized with the server is a part of future work. We have implemented the \move command optimization with the current visibility rules.

3.0 Network Protocol

The protocol between proxy and server is still in its initial stages. Before getting into the protocol, let us divide the messages which the proxy receives from its clients into 2 types.

Type 1: These are messages for which the proxy has code to process them. (i.e. it knows what to do with that message)

Type 2: These are messages for which the proxy does not have code to process them.

For Type 1 messages the Proxy-Server protocol is as follows.

(1)   Proxy forwards the message to the server through the corresponding socket.

(2)   The server receives the message. Assume that this message triggers a response from the server. We denote the response message as M. Now if M has to be sent to a subset of clients, the server will not send M to the clients which are connecting through the proxy.  This is because the server knows that the proxy has the code to handle type 1 messages.

For Type 2 messages, the normal Client-Server protocol is followed.

4.0 Proxy Server Architecture

In this section we show the organization of the source code of proxy server. We maintain a set of sockets in a set and use select() system call to monitor those set of sockets. The select() call will report the sockets which have changed status. We then do a read() from those sockets. Figure 4.0 shows the basic architecture. There exists a one-to-one mapping between the client sockets and server sockets.

Figure 4.0: Proxy Server Architecture

The code is organized into 5 modules. They are

(1)   Main module – Performs synchronous I/O multiplexing. Reads and writes to the sockets. (Figure 4.1)

(2)   Process Message – Determines the type of message. (Figure 4.2)

(3)   Process node change command – Parses the \nodechange command and updates the room information of the client. (Figure 4.3)

(4)   Process avatar command – Parses the \avatar command and determines the client’s room information. (Figure 4.4)

(5)   Process move command - Determines who are the clients that need to be informed of this move. (Figure 4.5)

Main Module

Figure 4.1: Main Module

Process Message module

                                               Figure 4.2: Process Message Module

Process NodeChange

                                           Figure 4.3: Process Node Change

Process Avatar

                                           Figure 4.4: Process Avatar

Process Move

                                              Figure 4.5: Process Move module

5.0 Conclusion and future work

We have done the initial implementation of the \move command optimization in proxy server. The next immediate work is to incorporate new rules to the current visibility rules to be in sync with Server. Future work includes optimization of other commands which are frequently transmitted and also exploring other possible ways of reducing the traffic in the wide area network.

References:

[1] Jeffery, C. (2005). Unicron – A Virtual Computer Science Community. Retrieved May 02, 2005, from New Mexico State University, Department of Computer Science Web Site: http://www.cs.nmsu.edu/~jeffery/vcsc/