5 IMPLEMENTATION 

5.1 Introduction 

This chapter discusses the implementation details of the framework. This includes the 

implementation of the 

HTTPQoS

 filter and the process of monitoring data streams to and 

from a HTTP server.  Where appropriate, source code or pseudo code will be used to explain 

how features were actually implemented. Finally, the configuration of the 

HTTPQoS

 filter 

on Jigsaw will be discussed.  

5.2 HTTPQoS Filter  

A key concern was the issue of the 

HTTPQoS

 filter implemented was that the filter should 

not have a significant impact on end user perceived performance for requests that are passed 

through the proxy. The 

HTTPQoS

 filter is applied to run against the client side HTTP API 

that Jigsaw uses to handle both request forwarding and reply caching. The 

HTTPQoS

 filter 

can catch requests before they leave the proxy and get replies as they come back from the 

origin server. This feature of the 

HTTPQoS

 filter is used whereby the 

ingoingFilter

 is called 

when the request is sent to the server and the 

outgoingFilter

 is called when a reply is 

returned from the server. If an exception occurs in the 

ingoingFilter

 or 

outgoingFilter

, an 

exception is caught and 

exceptionFilter

 is called.  

The fact that different methods are called in the 

HTTPQoS

 filter when a request is sent or a 

reply received allows specific parameters to be logged such as the time that a request was 

made and the time that a reply was received. The 

ingoingFilter

 gets passed the full request 

object so it can access the header fields and the entity body associated with the request. The 

ingoingFilter

 makes a call to a separate object called 

RequestDataMover

 that recorded the 

rate that the input stream associated with the request was returned from the server and passed 

to the client 

a

a

a

a