Browsermate: Surf with Your Friends!

BrowserMate: Surf with your friends!

By,

Andreas Anagnostatos, Dimitra (Mimika) Koletsou

CSE 291

Final Report

March 22, 2000

Introduction

While we surf on the Internet we often feel the need to comment on the content of a page we are viewing or furthermore, we would like to exchange opinions about the content with other surfers. The BrowserMate program is a client-server multi-threaded application written in Java that lets users browse the Internet as well as collaborate with other users with the same surfing interests.

Using BrowserMate, users that browse a page on the Internet have the option to view other users that are browsing the same page. Then they can collaborate using text-based chat or by exchanging audio clips.

Also, one might find BrowserMate an amusing way to make new friends that share common interests!

Related Work

From what we are aware of, none such application like BrowserMate exists so far, but there are some user-interaction applications that allow Internet users to exchange information. Such an application is ICQ ( with which you can retain a ‘friends list’ and have immediate communication with your friends through chat, instant messaging, transfer of files, link exchanging, etc. You can also subscribe to lists of your interest and interact with other subscribers.

Another user interaction application (plug-in) is implemented by AOL (America On Line) and it is called “Buddy List” and it is practically an instant messaging service, which is however restricted to AOL users only.

Design

Both the client and the server use UDP datagrams. The client-server model is shown below:

The software on the server side is designed as shown:

The server software is running two threads, the Listener and the Sender. The Listener listens for unicasts on port 5000. It strips the port number, which will be used for multicasting and then multicasts the rest of the message on that port using the Sender.

The client side holds all the complexity and its design is shown below:

The program interface in brief

The interface of the client is shown below:

Figure 1. BrowserMate’s client interface

As you can see, it has the typical interface of a common browser, although with less functionality. The Back, Forward and Stop buttons work the same as in any browser. The Friends button enables the user to view other people looking at the same page. By clicking on the Friends button the following dialog pops up prompting for a name and a server address to connect to.

Figure 2. ‘User and Server info’ dialog-box

From there on, the users can chat or record and send audio files to each other (functionality very similar with icq’s). The user can remain “invisible” by simply un-checking the “Visible” property in the ‘Options’ menu. That way he/she can view the list of people that are viewing the same page (unless of course, they are invisible themselves!) without being ‘seen’. By clicking on the ‘info’ button having a name of the list selected, we can view the user’s info. We did not have the time to implement the function of the ‘eBoard’ button, which should enable users to share a whiteboard where they could draw or write whatever. We decided that it is not really hard for one to implement it if they dedicate a reasonable amount of time.

BrowserMate on Details

As we stated before, the BrowserMate client has similar functionality to a common browser. Once we click on the ‘Friends’ button, the ‘user and server info’ dialog-box pops up prompting for a name and a server address to connect to. The port number is generated from the URL of the web page by using a hashcode and converted to a valid 5-digit port number between 10000 and 65000. After the user enters the information needed, the threads HeartBeatSender, Listener and Updater begin, and the window below pops up.

The application layer protocol for the client-server communication is:

Port# / Type of msg. / # of bytes in Name / Name / Message
5-bytes / 1-byte / 1-byte / Variable / variable

• Port#: this is the port that the server will use for multicasting the message to the other clients. It is generated be the URL.
• Type of message:

• 0 the message is a heartbeat
• 1 the message is text for the chat application
• 2 the message is audio
• 4 the message has coordinates used to draw a line
• 5 the message has coordinates used to draw a rectangle
• 6 the message has coordinates used to draw an oval

• # of bytes in Name: this field indicates the number of bytes used for Name so that the receiver can distinguish the Name from the Message

• Name: This is the name of the sender which is used to display it at the receiver
• Message: this can be anything from text used in the chat application to audio data to coordinates for the whiteboard.

HeartBeatSender. The HeartBeatSender thread generates a message of type “0” every 5 seconds and sends it to the server.

Updater. The Updater thread checks to see who hasn’t transmitted a heartbeat in the past 12 seconds and if someone stopped transmitting it removes the name from the list.

Listener. The Listener thread becomes a member of a multicast address and listens on the port generated by the URL. When something is received the listener determines the type of message and acts accordingly.

If the “visible” option is unchecked then the HeartBeatSender is disabled which makes that user invisible to other people but still able to receive information from them.

The user can open many Friends windows for different web pages that will show the list of people looking at those pages. For every copy of the Friends window a copy of each of the threads described above will instantiate.

The server does not do any analysis of the message. It receives the message in the format:

Port # / DATA

Strips the first field and forwards the rest of the datagram to the clients on the port# specified in the first field.

Implementation Issues

In order to implement BrowserMate, we used Visual J++ (version 6.0) from Microsoft. We found that pretty convenient due to the user-friendly development environment. We didn’t use already-built components, rather we implemented our own browser. As we discuss later, it’s unclear if that was the best choice, since there might be a way to implement our application as a plug-in for Commercial browsers (Internet Explorer, Netscape Navigator, etc).

Conclusion

The decision to use multicasting from the server to the clients has some advantages and disadvantages. Multicasting is more efficient because the server need only send one copy of a message to the router and the routers take the responsibility to deliver the message to all the clients that are members of that multicast address. If many clients on the same network want to receive the same message, only one copy of the message will be sent. The local router then replicates the message and forwards a copy to each of the clients thus saving a lot of bandwidth. Also by using multicasting, the server design becomes very simple. The reason is that the server does not need to keep group information on who should receive a particular message. By forwarding the message to the appropriate port, only the clients listening to that port will receive the message.

Multicasting, however, has a major disadvantage. Multicasting must be enabled by the routers involved, otherwise they simply drop the packets and the clients never receive them. Since you cannot guarantee that routers between the server and the client will have multicasting enabled, the communication becomes more unreliable.

Another thought that we made, while designing and implementing BrowserMate, was that it would be pretty convenient if we could implement our idea as a plug-in for a common browser (such Netscape Navigator, Internet Explorer), so that users wouldn’t have to use the BrowserMate client, but they could still use the browser of their favor. We could probably implement our component as a java applet, but we don't know whether it would be able to monitor the user clicking through arbitrary web sites or not.