Proximity

[600.647 - Advanced Topics in Wireless Networks]
Personal Networking Tool

Overview | Design | Implementation | Final implementation | Change log | Download

Components

User profile

Before joining the system a user must define his own profile. The profile contains information like name, nickname, email, location, interests, friends etc. There are 3 types of elements which define a profile:

Category - the basic element of defining profile; a category is defined by a name, description and value (examples: name, location, email); some default categories will be default by users can add their own categories.
Group - a group of interest (like JHU, Formula1 etc); any user can join a group by simply adding it in his profile; a 'General' group is defined but the user can add his own groups.
Friend- defines a direct friend.

Every 'category' and 'group' will have a policy which defines how that information will be passed to other users. There are 4 types of policies:

Public - information is provided to everybody who requests the profile.
FFriend - information is available for direct friends and friend's friends.
Friend - information is available only to direct friends.
Disabled - information is not available for anybody.
The 'friend' element does not require a policy flag since the profile of friends will be advertised based on their own policies (i.e if a friend of mine has a 'friend' category in his profile I will not publish that information).

A suitable format for the profile seems to be XML. The DTD schema might look like this:

<!ELEMENT profile (category*, group*, friend*)>
        <!ELEMENT category (name, description, value, policy)>
                <!ELEMENT name (#PCDATA)>
                <!ELEMENT description (#PCDATA)>
                <!ELEMENT value (#PCDATA)>
                <!ELEMENT policy EMPTY>
                <!ATTLIST policy type (public, ffriend, friend, disabled) "friend">
        <!ELEMENT group (name, description, policy)>
                  <!ELEMENT name (#PCDATA)>
                  <!ELEMENT description (#PCDATA)>
        <!ELEMENT friend EMPTY>
                  <!ATTLIST friend name CDATA #REQUIRED>
Profile example:

<profile>
        <category>
                <name>Username</name>
                <description>displayed name</description>
                <value>Londo</value>
                <policy type="public"/>
        </category>

        <category>
                <name>Name</name>
                <value>Londo Mollari</value>
                <policy>public</policy>
        </category>

        <category>
                <name>Email</name>
                <description>email address</description>
                <value>londo-nospam@deepspace-b5.com</value>
                <policy>ffriend</policy>
        </category>
    
        <category>
                <name>Location</name>
                <description>location</description>
                <value>Babylon5 Station</value>
                <policy>public</policy>
        </category>

        <group>
                <name>B5-Politics</name>
                <description>Babylon 5
                ambasadors</description>
        </group>

        <group>
                <name>Alpha Centauri</name>
                <description>Alpha Centauri
                citizens</description>
        </group>

</profile>

"Hello" sequence diagram

A first contact between two applications (APP1 and APP2) will take place as follows:

  • APP1 periodically broadcast a "Hello" message revealing his identity. The identity can be a minimal information about the user: full name, nickname, fingerprint of his certificate and a version number of his profile.
  • upon hearing the "Hello" message from APP1, APP2 will consult his profiles' repository, retrieve his profile, strip all information based on his policy and then the APP1 the resulting profile.
  • APP1 will store the received profile in his profiles' repository.

"Search Profile" sequence diagram

If a user became interested in a certain user (he can find about him by inspecting a list of friends of one of his friends) he can setup a periodic search for him. The message exchange will take place as follows:

  • APP1 broadcasts a profile query. To save bandwidth he can publish a list of profiles he is interested. If the list is really long he will split it in moderate size chunks and request them in a round robin fashion.
  • upon hearing the query, APP2 will consult his profiles' repository and if he has the requested profile and the policy allows him, he will send it to APP1.
  • APP1 will store the received profile in his profiles' repository and will remove the profile from the search list.

Network visualisation

Every profile contains a list of friends which can be used to build a connected graph. We plan to use a open source software (i.e OpenJGraph) for displaying the graph.

When a profile a friend is updated the network must be rebuilt (incremental operation).

Besides hiw own network, additional networks can be built using the collected profiles (based on various searches) which are not related to personal network a friends.

Online friends

The application will display a list of friends that are on-line (people that are on the same network). It will also display the list of unknown users on line.

This list is grouped by the interests of the people.

Apart from viewing a categorized list of friends, the user can also view his network of friends as a graph.

Other features: private chat, status messages etc

Two friends who are on-line can engage in a chat. Also a user can specify his preferences telling the system who can communicate with him. The software program will have options dialog where the user can specify one of the following:
  • Allow only my friends to contact me.
  • Allow the people in this list to contact me (* mean everybody).
  • Do not allow the people in this list to contact me (* means everybody)
When somebody contacts us, the application check to see our settings. If the person is allowed (as per the user setting) a chat window will pop up on the user's screen.

Otherwise the application sends the contacting person a CANT_COMMUNICATE message.

The chat will be private communication using user's IP address.

Also we plan to implement status messages wherein the application broadcasts status messages on certain events.

Last update: Wednesday, 11-May-2005 13:59:26 EDT