Technical notes on Everybuddy Java
Version 1.00.00
March 31, 2000

Everybuddy Java (EBJava) uses a client/server model internally, in addition
to the servers at the messaging services (ICQ, AIM, etc). The reasons for
this are to avoid requiring changes to security preferances in the running
of the applet, and to provide additional features above and beyond those
offered by the pre existing messaging services.

Since there is only a single TCP link between the applet and the server,
firewalls can more easily be configured to allow the full range of
capabilities of the communications program through. Also, this link can be
encrypted to prevent sniffing locally. Of course, the data will be back in the
clear between the server and the messaging service provider, but the local
subnet is probably the place to be most worried about security anyway.

Presumably, the server will be run on a computer with a dedicated high speed 
link. This would allow the server to perform actions for the user when he is
disconnected and to also filter communications only to what the applet needs
to receive, saving bandwidth over narrower end user connections, and to an
extent processing for slower end user computers.

As for the actual construction of the programs, they were built from the
beginning with modularity in mind. New protocols and extensions can be added
very easily. Only the greatest common denominator of messaging services was
implimented to insure that the concept of a unified interface to them all
would be doable.

Method calls to do anything that would be different from service to service
are forwarded to a class of methods for that particular service. The buddies
are each an instance of a class containing the information about the buddy
and the ability to forward the method calls to where they belong.

On the server side, a thread receives the stream and forwards high level
packets to the appropriate service's class which is running a different
thread maintaining a link to the service's server.

In general, a message is imbedded in the right service's protocol and
converted into a packet in the applet, which is multiplexed with other
packets and then sent to the server over one stream. The server reads the
header and hands off the packet to the right instance of the right
protocol's class, which does whatever it has to do to get the message to the
service. On the other side, the class receives packets from the service and
forwards what it needs to the service class in the applet. From there the
text message is sent to the correct instance of the buddy class, which
displays the message.

So you see, new protocols can be added by simply adding the service classes
in the applet and the server, then registering it in the stream readers.

The server maintains user information in two files per user: user.accounts
and user.contacts. It is done this way because EBJava was based on
Everybuddy. I chose to keep configuration files compatible, and this is
how Everybuddy does it. A part of the server receives commands from the
applet to do things like add user, remove user, and add accounts.

This program was written without many advanced features I would have liked to
include. For instance, the encryption I am going to use was written by
someone else (no sense in duplicating efforts) and I will migrate to the
Swing libraries too. Some JMF extensions might be included soon for
multimedia delivery. None of these would have been allowed for this contest,
but they are planned.