Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

Abstract
The finished Messenger application successfully achieves the following: Basic objective 1. Allows two users to communicate over a network using socket programming. 2. Users can send messages to each other. 3. Application manager user status (online and offline) is displayed. Intermediate objective 4. Supports multiple users tested 30 users successfully uses UDP Multicasting, see design section of this report for justification of technology. Advanced objective 5. Uses a GUI with menus, buttons, icons and hotkeys. 6. File transmission to individual user within chat. Files can be sent with sizes over the 101mb memory cap tested 400mb file successfully (6min, 20secs) and 10gb file on localhost (40seconds). Sends in a TCP stream over the same UDP port. Open and save dialogs on each end. File can be declined with appropriate handshake messages and responses. Specialized objective 7. Sending and receiving messages in HTML format for user name and the actual chat message independently. This allows for avatars in name using <img> tags, or images within the text. Other HTML tags such as bold, italics, tables and text size can be sent. Messages are appended within HTML body to be displayed incrementally. 8. Custom colour chooser supported on different operating systems. Can format name and message independently. 9. Viewing and saving chats to hard drive with dialogs supported on different operating systems. 10. Native platform look and feel and compatibility between platforms tested on Linux and Windows. 11. Ability to logout and rebind sockets without creating a new instance of the program. 12. Login manager to change login name and set a different port. 13. Only one port used, and two sockets one for sending and one for receiving. This includes file transfer as well as HTML messages. 14. Scrollbars and automated focus and caret positioning in colour choosing tags. Messages can also be sent using Shift + Enter keys. Enter alone sends a newline, converted to <br> html tag when sent.

Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

Design
Technology used and justification
The application has the ability to broadcast messages to multiple recipients. To do this, each messenger opens two Multicast sockets one to send and one to receive. This way, there is no server needed technically each instance of the application is its own server. The Multicast sockets are bound to a user set port number. They then join a group based on the IPv4 Multicast range of 224.0.0.0 through 239.255.255.255. The default IP in the application is 230.0.0.1 this is a reserved IP. For example if eighty users want to chat to each other in one huge chat, they can set the IP address to 230.0.0.1 and the port to 5000 and all talk. But if Fred and Sam wish to have a private chat only with each other, they can set the IP address to 230.0.0.1 and the port to 5001. The following diagram shows how the application uses UDP Multicasting to broadcast to more than two users on port 5000, while at the same time Fred and Sam are having a private chat and sending a message simultaneously on port 5001:
Multicast IP: 230.0.0.1 PORT: 5000 Mark James PORT: 5001 Fred

Chris

Ryan

Ed

Laura

Sam

Key

Messenger application

Multicast Receive socket

Multicast Send socket

Message broadcast

As you can see from the diagram, Chris is broadcasting a message to Mark, James, Ryan, Ed and Laura. Also note that Chris is broadcasting a message to himself. This is unavoidable as Chris is in the Multicast group and same bound port. But this is also a useful feature, as Chris will want to see the message that he has typed. At the same time, you can see what happens when messages are broadcast simultaneously. Fred & Sam both broadcast a message within the group and bound IP; they both receive their two messages. Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You This approach has advantages and disadvantages:

Christopher Willcocks

Advantages: Allows broadcasting to a huge number of users. Does not require a separate server to be run outside of the messenger. Automatically receives users own message does not require a dummy message. This is useful for displaying the sent message in a receive chat window. Does not require two-way-communication (a point-to-point channel) for communication between users. Works fantastically for quick LAN chats. Only two sockets are required for each messenger instance. Does not require a user database. Everything can be managed internally. Disadvantages: Data is broadcast using UDP there is no guarantee that the message will be delivered packet loss may occur so in a worst case the chat message does not get received. An open port is required.

Reason for chosen approach & alternative approaches

The only disadvantage with this approach is that it uses UDP above TCP. There are two alternative approaches for broadcasting to multiple recipients using TCP, but they have more severe disadvantages for what I wanted out of the messenger: 1. The first is to have a user database on each client with multiple TCP bridged connections this would require an inefficient increasing quantity of sockets for each user that joins the chat. 2. The second approach would be to have a separate server which relays TCP messages to the clients. The server would have one user database. Each client would send messages to the server. The server would then echo the messages back to all the clients sequentially. This would get slower as the quantity of users in the chat increases and with longer messages. I did not choose approach one as it seemed inefficient with socket usage. I did not choose approach two as I did not want a separate server and it also seems inefficient with the server having to quickly send lots of potentially large messages to lots of users.

File transfer approaches

File transfer needed to be implemented on top of the chosen UDP broadcasting system. UDP has two major problems which make it almost unusable for file transfer: Datagrams do not arrive in order. Datagrams may not arrive at all (packet loss). Originally I tried to implement a UDP file transfer by doing the following (follow order of arrows):

Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

Messenger: Alex
Send file transfer request to client with name James (broadcast to all clients) while (true) { // Receive packets

Messenger: James
while (true) { // Receive packets

if (request = James) { Send response confirmation to Alex. } if (chunk = James) { Append chunk to an indexed buffer. } if (complete = James) { Save buffer to hard disk. }

if (confirmation = Alex){ Split file into chunks and send one at a time to James When all are sent, send a completion packet to James }

Why this approach is unsuitable: This approach has an initial handshake and assembles the UDP packets in the correct order when appended to a buffer. However it does not take into account packet loss the only way to do this would be to have a checksum or confirmation check on each datagram followed by resending of the datagram if it fails. It is overly complicated and I decided to try a different direction: Different direction TCP: To integrate TCP with the broadcasting system, I used the initial handshake as shown in the above diagram to establish a connection with only two peers from a large group. I then opened a TCP stream on the same Multicast bound port between the two peers. This is shown in the following diagram:
Multicast IP: 230.0.0.1 PORT: 5000 A B D E

Key
Messenger application

Message broadcast

TCP Stream

Receive socket

Multicast Send socket

Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

As you can see from the diagram; A is broadcasting a message to everyone within the group however the message does not get received by C or F as they locked in the file transfer. However C and F can broadcast messages to everyone in the group, whilst downloading, as this is done on a separate thread although they do not receive their own messages. To conclude, this approach has advantages and disadvantages: Advantages: Allows guaranteed reliable data transfer of any file size. Tested 10gb file locally and a 400mb file successfully across the network. Simple integration with UDP message broadcasting system. Does not require an additional port to be opened. Only one handshake required. Disadvantages: The two peers in the file transfer cannot receive normal messages from themselves or anyone else within the Multicast group.

Reason for chosen approach:

I chose to use the integrated TCP approach as it provides reliable data transfer. Originally only 400 out of 600 datagrams were successfully received with the UDP approach making it completely unsuitable for large files. The new approach is simple, reliable and works on the same port. I could have solved the one disadvantage by opening another port just for file transfer; however I preferred the idea of only having to open a single port for the application.

Implementation
User guide
The application requires a machine with a java runtime environment installed. It requires a network with an unbound port. It is ready for distribution. Simply open the Messenger.jar file with the Java Platform SE Binary file to load a new instance of the application. You can talk locally by opening two (or multiple) instances of the application on the same port. You can talk across a LAN by opening instances of the application, on different machines within the network, on the same port. Click About > Help when in the application.

Exploded application guide

The following show exploded views of the application. The open, save and colour chooser dialogs vary from operating system to operating system depending on the default look and feel of the user interface manager. These screenshots are taken within a Linux environment:

Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

Above: Messenger loaded and file transfer initiated

Below: File transfer request received

This diagram shows the exploded view for when a download is received. If, at any stage, the downloader wishes to cancel a message is displayed saying X declined the file transfer to the uploader.

Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

Explicit code which was not developed by myself

I decided to use a Grid Bag Layout to arrange GUI components. I found this overly complicated to visualise manually and used the Eclipse Visual Editor plug-in to achieve it. This is annotated in the code wherever used. My TCP file transfer code was an adapted part of a sun tutorial as shown in the reference section of this document. My UDP broadcast code was also an adaption of this tutorial. Icons used in the application are freely distributable and licensed under the GPL and EPL (Eclipse Public License).

Relationships and requirements

The entire application uses ONE class and GUI components are created only during usage. Each major GUI component has its own get method which, when called for the first time, initializes the component else it returns the component. Read the annotations above the main method for more information on program structure. I specifically programmed the application way as it forced a modular approach. Also the HTML tags are purposely shown in the send input box. All specifications from Basic, Intermediate and Advanced requirements have been met except an implementation of a user database (advanced specification). The application does not need a user database as each client is its own server. Images can be displayed either by using file transfer or by using HTML <img> tags with the src pointing to a remote image in the message or login name (example if the user wishes an avatar by each message). Here is a basic UML diagram of the one class Messenger. Due to the class being too large, the GUI components and corresponding get methods have been omitted. Inheritance from its superclass has been shown:

Saturday, 01 December 2007

Distributed Systems & Networks assignment I Seek You

Christopher Willcocks

System analysis and conclusion

What works well
The following are the aspects which I believe work well in the application. HTML Messaging. File transfer reliability and GUI integration. Multiple user support. Visual appearance, simplicity of design. Shift + Enter messaging. Installation ease. Usage over LANs for example for LAN gaming.

What doesnt work well

The only disadvantage that I would comment on is not being able to chat while in a file transfer. In a worst case scenario on a huge file, the user can simply double click the Messenger.jar file and sign in as a new nickname to continue to chat to users on the port while in the file transfer.

What would I change?

I do not think I would approach any of the problems differently if I had to recode the messenger. I am satisfied with the result as I weighed up different technologies and chose the most suitable. It would be more functional to automatically create a new instance of the messenger during file transfer, or have a file transfer class which runs individually on a separate thread to enable chatting during the transfer. The finished application is very functional and works reliably, while fulfilling the specification objectives.

References
Listed are references besides the Java API and lecture slides, used in creation of the report and application: [21 November, 19:04] Used for help understanding sockets and TCP file transfer tutorial: http://java.sun.com/docs/books/tutorial/networking/sockets/index.html [24 November, 20:35] Used for learning how to implement UDP Multicasting: http://java.sun.com/docs/books/tutorial/networking/datagrams/index.html

The Eclipse IDE was used to create the application.

Saturday, 01 December 2007