Server Architecture Outline
- User Information
- Account Creation
- Authentication Systems
- Communications Threads
- Command Execution
- Event Mechanisms
- Server Persistence
- Security Considerations
edu.harvard.cduan.messaging.net.server.UserInfoThis class contains the following data:
- User name
- Profile string
- Away status and Away Message
- Permission for receiving broadcast messages
- Login date
- Autorespond string (for when the user is not logged on)
- Buddy information (described below)
Additionally, it is useful to keep a list of users who have a given user on their buddy lists. For example, when the server notifies users that a buddy has logged out, only users who have that user on their buddy list need to be notified. Since it is not necessary to associate group names with those buddies, a Set is used.
general architecture). Additionally, it requires that the server accept a connection for a user without the connector's identity being known, which presents both algorithmic and security issues. In order to work around these problems, the connection for creating accounts is run through another port, which is (for the purposes of this program) always one less than the port number for the server. A "manager" thread handles incoming connections. The classes containing these threads are:
edu.harvard.cduan.messaging.net.server.AccountMaker edu.harvard.cduan.messaging.net.MailboxThese classes use a highly primitive and insecure protocol, and it is suggested for future developers that they update these classes.
In this program's implementation of that algorithm, the server immediately sends the random challenge to the user and places that user's receiving thread (see below) into a "waiting pool" of unauthenticated users. All messages except for the authentication response are ignored. Once an authentication is received, it is checked for validity; if it is accepted the user is placed into the "active pool" and removed from the waiting pool; otherwise the user is logged off.
While this mechanism is fairly efficient, it does suffer from the one problem that it is possible for a malicious user to overflow the waiting pool by establishing connections which are never completed. Future developers may wish to implement a "cleanup" thread which removes threads from the waiting pool after a timeout period.
edu.harvard.cduan.messaging.Messengerwhich is described in the overview page. The messenger objects are hashed against the user names after being authenticated. When a message is received, the thread looks up the receiver's messenger object and redirects the message (hence the name ServerRouter). Special steps are taken if the message is being sent to the server or if the recipient is not online or away.
edu.harvard.cduan.messaging.net.server.ExecutableThe command parser looks up the first word in the string, matches it against a key in the hash table, and calls the associated executable class. The user is returned some Serializable object which is to be used as the return value of the command, as well as the command itself, in an object of type:
edu.harvard.cduan.messaging.net.server.ServerCommandPacketTwo especially useful commands for all users are ls, which lists all the user commands, and man, which provides information about a command (through its toString method).
Although the current implementation will respond to a command immediately after receiving the request, this should not be considered guaranteed. Future developers may wish to make the CommandParser into a queued thread, so that the server cannot be overloaded with command requests.
edu.harvard.cduan.messaging.net.server.ServerEventThese events include a user logging on, logging off, changing away status, and sending a broadcast message.
edu.harvard.cduan.messaging.net.server.ServerListenerThis is useful for implementing items such as an event log.
There is not yet a mechanism for installing a server listener during the execution of the program. To do so would be fairly simple; it should follow the model of the load command available to the superuser.
This presents a major security problem: since the passwords are unencrypted on the server, they may be easily accessed through the serialized state. Future developers may wish to consider the possibility of either encrypting the passwords in the server itself or encrypting the output file.
Additionally, communications are not encrypted. A simple improvement that could be made by developers knowledgeable in encryption would be to encrypt the contents of packets. Since the server never reads the contents of a packet--it just routes it--the packet's contents could easily be secured.