The Computer Communication Lab (236340)

Projects Done in Spring 2000

 


 

A switch for network behavior study

TCP protocol analyzer

HTTP over UDP

Light DHCP Server

Cache Replacement Algorithm for Proxies

Smart Caches

Connection Management and Request Dispatching in HTTP

 


A Switch for Network behavior study

Instructors:

Itai Dabran - LCCN, Uri Keidar - Attune

 

This project will be an Ethernet LAN switch that will be connected to a number of LANs and will study it's environment. This switch will be able to do the following:

    1. Support VLANS
    2. Support a User interface with the following features:

      1. Error injections
      2. Delay
      3. Jitter
      4. Bandwidth control
      5. Packet loss.

All of these can be applied from One to One station, from One to Many stations, and from Many to One station.

 

The project will be developed on Windows NT environment, using Visual C++ and Java, a MAC software package and graphic tools.

Top


TCP protocol analyzer

Instructor: Itai Dabran

 

The TCP protocol analyzer will be a software gateway (Windows NT connected to two 100BaseT LANs), which will be able to inject some parameters such as Delay, Errors and Bandwidth.

On one of the LANs there will be a predefined (IP & MAC) client. On the second LAN there will be one predefined gateway. According to the user request, the simulator will touch every packet directed to the gateway, or - will touch every IP packet directed to the gateway (MAC Layer), but with destination address (IP Layer) not of the gateway.

The analyzer will have a monitor for incoming data, and for out-coming data.

It will measure and display a graph of some TCP parameters such as: Delay, Effective Window Size, Declared Window Size, Slow Start, Fast Retransmission, Failures in establishment, Reset Connection.

The project will be developed on Windows NT environment, using Visual C++, a MAC software package and graphic tools.

You may use modules from similar projects that were done here:

Satellite Channel Simulator 1

Satellite Channel Simulator 2

 

Top


HTTP over UDP

Instructor: Roman Vitenberg

According to the specifications, HTTP can be build upon any reliable p-2-p transport protocol. However, virtually all existing implementations of HTTP are based on TCP. While using TCP perfectly makes sense for long-term connections (e.g., for transferring long files), it has a significant initialization time and self-tuning phase that make TCP inefficient for short sessions. Ironically, most messages of a typical HTTP traffic are just short control queries and notifications (especially, conditional GET and response to it).

In this project you should implement a simple client and a proxy that act according to the following protocol:

  1. Both the client and the proxy listen on two ports: one TCP port and one UDP port.
  2. If the client wants to issue a short GET or HEAD request, it will send the request to the UDP port of the proxy.
  3. Other requests are handled in a usual way by connecting to the TCP port of the proxy.
  4. The proxy action upon receiving a UDP request depends on the length of intended response message: Short responses are merely sent to the UDP port of the client.
  5. In order to return long responses (e.g., long files), the proxy connects to the TCP port of the client and sends the response just as if the client sent the request through this TCP connection.

One complication with this scheme is that UDP is an unreliable protocol. In order to guarantee that requests and responses arrive at their destinations, some retransmission mechanism should also be implemented.

In order to enable conditional GET, a client should maintain some primitive kind of cache. If the document required by the user is in the cache, a client issues a conditional GET request in order to check that the document in the cache is fresh.

As part of the project, you should compare performance of the suggested scheme with that of the standard one.

The project can be implemented on either NT or Linux, in either Java or C++. Furthermore, proxy and client can be implemented in different languages. You are advised to make use of existing client and proxy implementations as well as of other projects done in the lab.

The project is intended for a group of 4 students.

Resources

  1. HTTP 1.1 - rfc2616
  2. libwww
  3. Jigsaw and Apache servers
  4. Squid proxy
  5. other projects done in the lab
  6. traces
  7. benchmark suites

    1. Wisconsin Proxy Benchmark
    2. Web Polygraph

Top


 

Light DHCP Server

Instructor: Itai Dabran

 

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism through which computers using TCP/IP can obtain protocol configuration parameters automatically through the network. The DHCP server is typically centrally located and operated by the network administrator and DHCP clients can be reliably and dynamically configured with parameters appropriate to the current network architecture.

DHCP carries important configuration parameters, the most is the IP address of a client and others are subnet mask, default router and Domain Name System (DNS) server.

In this project you will develop a Java DHCP server. The project will be developed on Windows NT environment.

You may find a useful information at:

http://www.dhcp.org/

 

Top


 

Advanced Encryption Standard implementation - project 1

Advanced Encryption Standard implementation - project 2

 

Instructor: Itai Dabran & Elzur Uri , Intel

 

AES (Advanced Encryption Standard) is a new encryption protocol that is being standardized by the NIST (National Institute of Standards and Technology) as the new protocol for IPSec (IP Security). Currently there are 5 protocols that are contenders for selection.

The project objective is to compare two protocols from the 5 contenders. To do that the students will need to learn IP, IPSec and the new protocols. They will develop SW that implements the protocol and validate the implementation according to NIST standard tests. The comparison should indicate relative code complexity, MIPS requirements, HW implementation implications and cryptographic strength.

Advanced Encryption Standard - crypto for the next century

Advanced Encryption Standard (AES) Development Effort

 


 

Cache Replacement Algorithm for Proxies

Instructor: Roman Vitenberg

 

While LRU and LFU are known to perform reasonably well for Web caching, they might not give the best response time since they do not take into account the different objects have different size and loading cost (see the following paper). Therefore, various web cache replacement algorithms has emerged, e.g. Hybrid and GreedyDual-Size. However, it is not fully explored yet how these algorithms compare to each other.

Furth, no existing algoritinto account the topology of proxy hierarchy existing in the world. However, this information can also be important for decision which object to evacuate from the cache.

The aim of this project is to assess different replacement algorithms and compare their performance. To this end, a proxy should be built that manages a cache with configurable replacement algorithm. In addition, a simple configuration tool and cache monitor should be built with a fancy GUI. This tool enables to select the required cache replacement algorithm and to visualize the cache statistics.

The replacement algorithms to be implemented are LRU, GreedyDual-size, Hybrid and the algorithm which takes into account knowledge of hierarchy (its details will be introduced later). Note that Hybrid and GDSize require recording bandwidth and latency to the servers from which the document was brought, based on the time taken by the transfer.

Performance will be measured in the following way: A pre-defined hierarchy of 2-3 proxies will be launched in a LAN in order to simulate a real proxy hierarchy (artificial delays should be used for simulating a WAN). Each proxy will read URI requests from real proxy traces and fulfill them recording hits, misses and response times.

You are advised to take an existing proxy implementation (Jigsaw or Squid) and port it for your needs. These implementations are known to be more stable on Linux but can run on NT as well. You can also make use of another project done in the lab.

The project is intended for a group of 3 students.

Resources

  1. HTTP 1.1 - rfc2616
  2. libwww
  3. Jigsaw and Apache servers
  4. Squid proxy
  5. other projects done in the lab
  6. traces
  7. benchmark suites

    1. Wisconsin Proxy Benchmark
    2. Web Polygraph

Top

 


Smart Caches

Instructor: Roman Vitenberg

 

Obviously, information retrieval can be more efficient if the document structure is known in advance. For example, if the proxy knows that a given HTML document contains several embedded objects (e.g., pictures), it can transfer these objects along with the document itself whenever the document is requested.

In this project you will build a proxy whose cache keeps information about object structure. Specifically, this strategy will be tried for applets. Whenever a proxy contacts another proxy for the main applet class, the second proxy transfers additional classes to the first one along with the requested class.

All combinations of Java/C++, Linux/NT, porting/writing from scratch are possible. The project is intended for a group of 2-3 students.

Resources

  1. HTTP 1.1 - rfc2616
  2. libwww
  3. Jigsaw and Apache servers
  4. Squid proxy
  5. other projects done in the lab
  6. traces
  7. benchmark suites

    1. Wisconsin Proxy Benchmark
    2. Web Polygraph

Top


Connection Management and Request Dispatching in HTTP

Instructor: Roman Vitenberg

 

The greedy connection management of HTTP 1.0 in which a separate connection was opened for each request was literally choking the Internet. HTTP 1.1 has introduced persistent connections and limited the number of simultaneous connections between the same server-client pair to 2. Since then, web applications consume less bandwidth and induce a lighter load on servers/proxies. It does not come free, however: Persistent connections require sophisticated management, and constraint on the number of connections increases the response time. In order to compensate the clients for worse response time, the HTTP 1.1 specification defines many optimizations, e.g., request pipelining. These optimizations complicate the protocol even more, so no existing implementation managed to catch up and be fully compliant with the standard.

The goal of this project is to implement some of the HTTP 1.1 improvements in a proxy and a client and investigate their impact on system performance and stability. The features to implement are:

  1. Request pipelining
  2. Smart and HTTP 1.1 compliant connection management:
  3. Utilization of maximum allowed number of connections if and only if it is estimated to improve response time.
  4. Caching idle connections and closing them with care.
  5. Probing the document length with HEAD request in order to check whether an additional conshould be open.
  6. Monitoring connections by client for error status messages.
  7. Thread management.
  8. Request persistence: If the server closes a connection in the middle of request transfer, the request should be retransmitted (see more detailed description in RFC 2616). If connection was closed in the middle of long response transfer, "Range" request should be used for the missing part of the document.
  9. Chunked transfer encoding.

 

You should implement a control tool with a fancy GUI that allows for configuring the use of these features. Both a proxy and a client should be able to log their actions related to connection management.

Your client should support a command-line mode and a batch mode, similarly to the clients existing in the libwww library.

Both client and proxy should be implemented in Java on Linux or NT. You may partly use the Jigsaw code, e.g., for HTTP and HTML parsing. You should also look at connection and thread management in Jigsaw but you have timplement it yourselves (actually, your algwbe different). Another project done in the lab implemented persistent connections and request pipelining.

The project is intended for a group of 3-4 students.

Resources

  1. HTTP 1.1 - rfc2616
  2. libwww
  3. Jigsaw and Apache servers
  4. Squid proxy
  5. other projects done in the lab
  6. traces
  7. benchmark suites

    1. Wisconsin Proxy Benchmark
    2. Web Polygraph

Top


Staff (in spring 2000)

 

Lecturer : Prof. Hagit Attiya

e-mail: hagit@cs.technion.ac.il  

 


Instructor in charge: Itai Dabran

e-mail: idabran@cs.technion.ac.il


Instructor: Roman Vitenberg

e-mail: romanv@cs.technion.ac.il