In this chapter we present our system implementation in details. Our system was developed using C++. CCLSIP UA, a SIP communication system, Chord DHT and IP were used to built MFPGC system. Figure 4.1 depicts the layered structure of MFPGC system and all MFPGC messages.
Join Reply ChangePre FindPre
RePre Publish Query Store
CallYou CYReply KAL Re_KAL
Leave
Figure 4.1 Layers of MFPGC system and the MFPGC messages
4.1 System components
Our system supports three types of nodes with different functionalities according to the capability of nodes; There are P2P nodes, non-P2P nodes and PDA nodes. Figure 4.2 depicts the communication modes between the components, and Table 4.2 lists their differences that we will describe in more details.
.
Figure 4.2 The three types of components in MFPGC system
Table 4.1 The differences between the three components
components DHT routing Store user profiles
Publish and query
GPS Location information
P2P node Y Y Y N
Non-P2P node N N Y N
PDA node N N Y Y
4.1.1 P2P node
P2P nodes are the back-bone of our system and provide all of the peer-to-peer functionality including routing, storing user profiles, and communication functions - publishing, query, and communications. Based on the design of Chord, a P2P node should maintain a finger table and a backup successor list for routing purpose. Each P2P node maintains a thread that periodically sends keep-alive messages to each node in its finger table, so that the node can rebuild its finer table when any node ungracefully left the Chord ring.
Each P2P node maintains another thread listening a network socket and handles MFPGC messages received. The node also maintains a database to store user profiles published by MFPGC users. When users publish their profile or attributes, MFPGC will read the attributes from database and publish them. When a P2P-node receives the published attributes of other users, it will store them in the database too.
4.1.2 Non-P2P node
Non-P2P nodes are peer-to-peer nodes without node IDs, and thus cannot provide peer-to-peer functionalities; they provide a lightweight scheme for nodes with less computing, storage, and/or networking capabilities. A non-P2P node would use a P2P node as a gateway to send MFPGC messages. The gateway P2P node of a non-P2P node could be a famous node or a node assigned by famous nodes. Since non-P2P nodes have no node ID, P2P nodes will not add non-P2P nodes to their finger tables, and thus no DHT message will be forwarded to non-P2P nodes. The only messages sent by a non-P2P node are Publish and Query which contain the IP address and port number of the non-P2P node for future communications. By using the IP information, other nodes can directly connect to non-P2P nodes without node IDs. In other words, the basic functionalities of non-P2P nodes are publishing user profiles and sending the query of a call request..
4.1.3 PDA node
PDA nodes are non-P2P nodes on PDA devices; they may be equipped with GPS functionality for location-based applications. The MFPGC system on a PDA is based on a mini SIP UA, CCL-UA, implemented on Windows Mobile platform. Note that CCL-UA was developed by CCL, ITRI. The user’s location attribute can be directly obtained from the GPS module on board. The design of PDA nodes is the same as that of non-P2P nodes.
4.2 Bloom filter implementation
As we have described in Chapter 3, MFPGC system uses Bloom filter to represent user attributes. The Bloom filter we used is a 512-bit array, and MD5 hash function is used to hash a user attribute to 8 array positions. In order to generate 8 indices, we used the same hash function but with 8 different input texts for a given user attribute. The 8 different input texts are obtained by concatenating the original text and a number of 0’s.
For example, consider a system-defined attribute “Club:Bridge”. We hash “Club:Bridge”,
“Club:Bridge0”, “Club:Bridge00”, …, and “Club:Bridge0000000” to 8 indices and set those positions of the bit array to 1.
4.3 Message encryption
Figure 4.3 The encrypt process in query
In MFPGC system, a caller can add a short message in the query of a call request to invite the callee to call back. The Callee can read the message and decide whether to call back or not. Since a query message is first sent to the corresponding node of an attribute in SNAS, to provide confidential communications, the query message can be encrypted
using Advanced Encryption Standard (AES) algorithm. The encryption key used in AES is the hash value of the string concatenating all attribute names and values in SNAS in an increasing order of the attribute name. The query message also includes, in plain texts, all the attribute names of SNAS, but not their values. The corresponding node cannot
decrypt the message since it does not have the attribute values of SNAS. When a matched callee receives the query, the callee can use the attribute names of SNAS, which is in plain texts) and the callee’s own attribute values of SNAS to find the key of AES because each attribute of SNAS must be the same as the attributes of the matched callee.
Furthermore, the attribute and value pairs of SAS can also be included in the query message of a call request, and SAS can also be encrypted using the same approach. In this way, a matched callee can decrypt the SAS of a query can check false positives.