CS 519 Final Project Report

Internet Phone

Date: Dec. 4, 98

Name of Group : G1

Team members: Jing Deng, Rung-Hung Gau

Task: Accounting (#5)

We divide our project into four components, database, interface to other teams, security, billing, and pricing. We choose MS-Access in Windows 95/NT as our database and use the JDBC/ODBC Bridge so that we can use our Java codes to manipulate the database. When we handed in report 2, our Java codes could perform various database operations, such as query, read and write, using SQL. We are currently on schedule.

We next moved to implement the interface to other teams. We had a group meeting just after handing in report 2 and decided to use RMI to provide interfaces to other teams. Our program has to interact with programs of signaling team and directory team. We currently assume all calls can be classified into four categories. A call can be made from a phone to a phone or host. It can also be made from a host to a phone or host. We provide four corresponding classes in the package InternetPhoneEntry to maintain information about an Internet Phone call. We need signaling team to inform us whenever a call is initiated or terminated. We show the interfaces to signaling team in a Java interface, Accounting, and a Java class, AccountingImpl, which actually implements the above interface. We have two more Java classes to demonstrate our program. The class AccountingServer provides an RMI interface to the AccountingClient class, which mimics a simplified version of codes of signaling team. The AccountingClient class can obtain a stub from the AccountingServer and can perform remote method invoke to update our database.

In order to obtain the identity of a customer, our program has to call program of directory team. We basically need two types of services from directory team. We like to know the identity of a customer, a caller or callee, given a phone number or a socket address. We also write a simplified program for directory service, named DirectoryServer, based on the codes provided by directory team. We test our program by running three classes, AccountingClient, AccountingServer, and DirectoryServer. First, the AccountingClient invokes a remote method, InformAccountingCallInit, in AccountingServer when a call is initiated. The method InformAccountingCallInit in turn invokes a remote method, GetNameByAddress, in DirectoryServer, to obtain the identity of a customer and updates the database accordingly. The AccountingClient also calls the AccountingServer when the above call is terminated. Then, the AccoutingServer runs a billing algorithm and updates the database.

After finishing the RMI stuff, we work on security issues. We focus on authentication due to the nature of our project. We adopt DSA, Digital Signature Algorithm, in Java to discern the signaling team and to make sure that the message is not distorted. DSA uses public keys and private keys to verify a user and is very similar to the well-known RSA algorithm. We create three object classes that are required for DSA and put them in a package, called DSAInstance. The security package of Java provides three relevant interfaces for DSA, DSAParams, DSAPublicKey, and DSAPrivateKey. We want to store public keys and private keys in files so that we can distribute them. However, we can not directly save these keys. We figure out that this is due to that DSAPublicKey and DSAPrivateKey are only Java interfaces instead of Java classes. We create three classes corresponding to three interfaces mentioned above. Since both interface DSAPublicKey and DSAPrivateKey are serializable, we are able to save keys in files using object streams in Java.

We also create a class, AuthenticationByDSA, to allow other teams apply DSA easily. The class provides several methods so that programmer can get a private key or public key from a file. The class also allows a programmer get a digital signature and verify a digital signature easily by two class methods. We design another class, DSAKeysGenerator, to generate several private keys and public keys and to save these keys in files. We use a class, SignatureTest2, to test our programs. The testing program first reads a private key from a file and uses the private key to sign a message. Then, it reads public keys from files and tries to verify the signature. Our testing program uses private key 5 to create a digital signature and it is able to show that the message is indeed signed by private key 5 instead of any other private keys. This justifies the correctness of our program.

We decide to adopt a two-phase billing algorithm for its flexibility. In the first phase, we calculate the charge for each call when a call is terminated and write the charge in the database. In the second phase, we decide who should pay how much for a call according to our policy. For example, we can calculate the cost for a multi-party conference in the first phase while leaving the amount each participant should pay undetermined. In the second phase, corresponding to the bill creation date, we calculate the due amount for each participant. This scheme is flexible since the service provider only decides the charge for an Internet Phone call, for example a multi-party conference. Participants of a call can decide how to share the charge and inform the service provider. Currently, we decide to use the popular scheme in which the caller pays all the charge in order to test our program. The cost is 9 cents per minute 24 hours a day, 7 days a week. We choose the rate to be a little below the regular long distance call in order to compete with long distance phone companies.

We find some papers [5] [6] [7] [8] [9] [10] about pricing the Internet. MacKei-Mason and Varian [5] provide answers to some frequently asked questions about Internet pricing. They argue that usage-based pricing is necessary for congestion control in Internet and propose "smart market" to implement usage-based pricing in their paper [6]. P. Jones [7] concludes that the problem of sharing network resources in Internet is still not well understood. Mills, Hirsh and Ruth [8] discuss architecture for Internet accounting. Instead of focusing on economic issues, they concentrate on technical aspects of Internet accounting. Gupta, Stahl and Whinston [9] use simulations to show that pricing can improve Internet efficiency compared to free-access policy.

MacKie and Varian claim that pricing in Internet is necessary according to the following reasons. First, the traffic of Internet can be expected to grow steadily and quickly based on past statistics and network congestion can not be avoided without introducing new control and management mechanisms in Internet. Many priority-based mechanisms have been proposed to achieve efficient utilization of network resources during congestion period. However, those priority-based mechanisms require cooperation among all users and users who do not cooperate tend to benefit. They argue that priority-based mechanism can not work without using pricing to enforce cooperation. Once pricing is adopted, priority can be based on the money a user is willing to pay. Therefore, we do not need a centralized scheme to set priority for each packet. They suggest using "smart market" to perform per packet pricing.

Although their idea looks attractive and promising from economic point of view, we think some technical issues have to be resolved before "smart market" can be implemented. First, we think the overhead to perform per packet pricing tends to be very high. We expect the throughput of network to decrease significantly due to the huge amount of packets. They propose sampling method to reduce the overhead. However, we doubt that a sampling method is reasonable in a connectionless network. Second, we do not think that per packet quality is sufficient for all applications. It is clear that some applications, such as voice and video, require constant quality of service. Giving higher priority to a packet does not ensure that all packets from an application will be given higher priority since network is dynamic. In smart market, the price is relative, not absolute. A voice application may be interrupted because some users are willing to pay more in the near future. They admit that their pricing mechanism does not ensure absolute quality of service. We conclude that the pricing mechanism must be complemented by some reservation mechanism to provide absolute quality of service.

Another technical issue of the "smart market" is how and who should know a packet is successfully delivered in order to charge a user. In smart market, a bid value is set in each packet. Each user, whose packet is admitted, pays the amount equal to the bid of the rejected packet with highest bid. This implies that we need divide time into slots to compare bids to perform admission control. It also implies we need centralized control to compare bids of packets from scattered networks. Without resource reservation, a packet is not guaranteed to be delivered successfully even it has been admitted. This is frustrating since a user who pays only gets a higher chance, instead of a warranty, to deliver his/her packets. On the other hand, we need much more overhead if we charge a user only a packet is delivered successfully since we have to trace each packet.

We encountered some technical problems in Java programming. The first one was about Remote Method Invoke. Although the book from Sun Microsystem [2] illustrated how to use RMI in a simple client-server model, it did not tell us how to deal with a object that is a client and server at the same time. Fortunately, our program worked after several tries. Another technical problem we had is how to save a private key. It took us less than an hour to create a public key and private key, to obtain a digital signature using a private key, and to verify a digital signature using a public key. However, we could not save these keys in a file although both a private key and a public key are serializable in Java. We solved the problem by noticing that a private key, DSAPrivateKey in Java security package, is a Java Interface instead of a Java Class. In order to save a private key in a file, we had to create a Java object class, which implements the Java interface. Then, we could write and read keys from files through object streams of Java.

We also had some difficulties in coordinating our works with others and they are sometimes more serious than our own technical problems. When we were ahead of other teams, we did not have programs from other teams to test our programs. Consequently, we had to write a simplified version of their programs for our testing. We guessed this situation also happened in industry and we should reach agreements in interfaces as early as possible and designed some testing programs so that the team in trouble will not stop the progress of other teams. Of course, we should try to avoid becoming the team causing troubles.

We learned a lot about advanced Java programming including Socket Programming, Remote Method Invoke, Object Streams, and Security. We learned how to work with other people. We also know that people with different background and academic training can have very different point of view especially from some papers written by economists.

We will try to get familiar with essential technologies before we start our projects. We did not have any experience in Java programming before this semester although one of us had some experience in C++. We learned Java while doing our project. For students, this methodology may be acceptable although we got frustrated and wondered if we could finish our project before due date several times. However, we would like to make sure that our team members have enough skills for a project if we were project leaders in industry in the future. We would try to minimize the risk of a project although we understand that this situation may not always be avoided.

We provide two methods to signaling team as the following. The first line provides the RMI interface to signaling team. The signaling team calls the method in line 2 when a call is initiated. The signaling team calls the method in line 3 when a call is terminated. Both of the above methods are overloaded. The object passed through this method can be another type of object depending on the type of an Internet Phone call. We attach a class, AccountingClient, to show the procedures.

We need two methods from the directory team. The first line gets the RMI service from directory team. We can get the identity of a customer with a hostname by using the method in line 2. We can get the identity of a customer with a phone number by method in line 3. We can get the identity of a customer with a socket address by method in line 4.

It seems that we proceed quite well at this moment. However, we do need another Windows 95/NT machine with MS-Access and Internet connection to run our codes in the final demo because our dedicated machine is installed with Linux only.

[1] Barry Holmes, "Programming with JAVA" is the first book we used to learn JAVA including window programming in Java.

[2] Cay S. Horstmann, Gary Cornell, "Core Java 1.1 Volumn II- Advanced Features" is the book we use to learn JDBC, RMI, Object Streams, and DSA.

[3] W. Richard Stevens, "Unix Network Programming" is the book we used to learn socket programming.

[4] http://www.sun.com/java

[5] Jeffrey K. MacKie-Mason and Hal R. Varian, "Some FAQs about Usage-Based Pricing", University of Michigan, September 1994.

[6] Jeffrey K. MacKie-Mason and Hal R. Varian, "Pricing the Internet", University of Michigan, February 1994.

[7] P. Jones, "RFC 1346: Resource Allocation, Control, and Accounting for the Use of Network Resources", June 1992.

[8] C. Mills, D. Hirsh, G. Ruth, "RFC 1272: Internet Accounting: Background", November 1991.

[9] Alok Gupta, Dale O. Stahl, and Andrew B. Whinston, "Pricing of Services on the Internet", University of Texas at Austin.

[10] Alok Gupta, Dale O. Stahl, and Andrew B. Whinston, " An Economic Approach to Networked Computing with Priority Classes", University of Texas at Austin.