Controlling
Transmission Order of Inline Objects
for Effective Web Page Publishing
Tadashi NAKANO*, Kaname HARUMOTO**, Shinji SHIMOJO**, and Shojiro NISHIO*
*Department of Information
Systems of Engineering
Graduate School of Engineering, Osaka
University
2-1 Yamadaoka, Suita, Osaka 565-0871,
Japan
{tnakano, nishio}@ise.eng.osaka-u.ac.jp
**Computation
Center, Osaka University
5-1 Mihogaoka, Ibaraki, Osaka 567-0047,
Japan
{harumoto, shimojo}@center.osaka-u.ac.jp
ABSTRACT
Due to the increasing popularity of the Internet, the WWW (World Wide Web) has become the most popular way to distribute multimedia contents. In the WWW, impressive information can be provided by embedding a large number of inline objects such as images in a WWW page. Since these inline objects are generally presented on a WWW browser with the order of transmission, the transmission order of inline objects becomes very important, especially for users accessing the Internet with a low-speed link such as a dial-up line. In this paper, we propose a page transmission mechanism which allows content providers to specify the transmission order of inline objects in WWW pages. First, we define a language to specify the transmission order of inline objects. We then discuss how we can implement the transmission order control, and propose a new protocol, HTSP (Hypertext Streaming Protocol), which realizes efficient transmission of ordered inline objects.
Keywords
WWW, inline object, transmission order
1 INTRODUCTION
Due to the increasing popularity of the Internet, the WWW (World Wide Web) has become the most popular way to distribute multimedia contents. Since we can now easily access the Internet via dial-up links, the WWW is extensively used for various purposes including advertisement, entertainment, and individual information publicity.
In the WWW, impressive information can be provided by embedding a large number of inline objects such as still images, animated images, and background sounds in a web page. However, the total data size of the inline objects is usually so large that it takes a long time for a client to get all the inline objects in the web page in the case that the available network bandwidth between the client and the web server is narrow. Therefore, users often terminate the transmission of the web page before all the inline objects are successfully transmitted, which causes a great loss especially to companies which do business on the WWW.
In order to solve this problem, an effective page transmission mechanism is required. In [1], we have proposed a WWW server with media scaling mechanism as one possible solution. The proposed server can control the transmission time of web pages by dynamically controlling the quality of inline images, hence users can get a web page within tolerable time. However, some users may not be satisfied because there are cases where the quality of inline images is much degraded. Thus, as another possible solution, we discuss transmission order control of inline objects in this paper.
The transmission order of inline objects is very important especially for users accessing the Internet with a low-speed link such as dial-up line, since inline objects in a web page are generally presented on web browsers with the order of transmission. If we can control the transmission order, we can obtain the following advantages.
By transmitting some of the inline objects which users should be interested in prior to the other inline objects, we can reduce the user-perceived latency. For example, in a page describing a product lineup of a company, it is conceivable that the images users are interested in are those of new products. Therefore, transmitting the new product images prior to old product images is considered to be effective. In a top page of a web site, transmitting images used in links prior to other images is also effective because users can immediately follow the links.
By transmitting images for advertisement prior to other images, content providers can effectively announce something to be advertised.
In recent web pages, one large picture is often divided into some small images for several purposes, such as for assigning each region a different link. In such cases, transmitting those images in parallel is effective because users can get a quick preview of the whole picture.
However, in the current situation, the transmission order of inline objects depends on the implementation of web browsers and content providers cannot control it. Although there are some specification languages related to the presentation of web pages, such as CSS (Cascading Style Sheets)[4], SMIL (Synchronized Multimedia Integration Language)[5], and HTML+TIME[6], none of them can be used to specify the transmission order of inline objects. Therefore, we propose in this paper a transmission order description language and discuss how we can realize the transmission order control.
This paper is organized as follows. Section 2 presents a transmission order description language. In section 3, two methods for implementing the transmission order control are discussed. Some experimental results are then presented in section 4. Finally, we conclude the paper in section 5.
2 TRANSMISSION ORDER DESCRIPTION LANGUAGE
In this section we define a language to specify the transmission order of inline objects in WWW pages.
2.1 Language Specification
In the proposed language, content providers can describe the transmission order of inline objects in the head section of the HTML document. Each inline object whose time order is specified must be assigned a unique identifier in the HTML document, and is referred to with the identifier in the description of the transmission order. The transmission order is specified by four elements: seq (sequential transmission), par (parallel transmission), xfer (transfer of an inline object) and dto (description of transmission order). Below we describe the syntax and semantics of these elements along with their usage through examples.
2.1.1 The seq element
A seq element indicates sequential transmission of inline objects. It must contain one or more xfer elements (see section 2.1.3). The following example indicates that three objects with identifiers A, B and C are to be transferred in sequential order.
<seq>
<xfer object="A"/>
<xfer object="B"/>
<xfer object="C"/>
</seq>
2.1.2 The par element
A par element indicates parallel transmission of inline objects. The description is almost the same as the seq element. However, this element must have the slice attribute, which is explained in section 3.1. The following example indicates that three objects with identifiers A, B and C are to be transferred in parallel.
<par slice="10">
<xfer object="A"/>
<xfer object="B"/>
<xfer object="C"/>
</seq>
2.1.3 The xfer element
An xfer element indicates transfer of an object identified by the value of the object attribute, and it can also be used to specify transfer of a fragment of the object. In the case of specifying a partial transmission, either of the following attributes can be used.
We show two examples of this effective use of the partial transmission.
<seq>
<xfer object="A" volume="50%"/>
<xfer object="B"/>
<xfer object="C"/>
<xfer object="A" volume="50%"/>
</seq>
The same transmission order can also be specified using the range attribute as follows.
<seq>
<xfer object="A" range="0%-50%"/>
<xfer object="B"/>
<xfer object="C"/>
<xfer object="A" range="50%-100%"/>
</seq>
<seq>
<xfer object="A" volume="1f"/>
<xfer object="B"/>
<xfer object="C"/>
<xfer object="A" volume="rest"/>
</seq>
2.1.4 The dto element
A dto element encloses the transmission order description. This element can have the following attributes.
The rest attribute is used to specify the transmission order of inline objects for which the transmission order is not explicitly specified. Those inline objects will be transmitted after the transmission of the inline objects for which the transmission order is explicitly specified, either in sequential order or in parallel according to the value of this attribute. The possible values are ‘seq’ and ‘par’.
2.2 Example
Figure 1 presents an example of the transmission order description in an HTML document. We show how the inline objects are transmitted based on the description. This WWW page contains one important image, and one picture consisting of three interlaced images and one animated image. Moreover, a background sound and many other images are embedded. Based on the description, the important image is transferred first. Next, four partial images are transferred in parallel so that it gives the users a quick preview of the full picture. Following that, the background sound, the rest of the frames of the animated image and other images whose transmission order is not specified are transferred. This transmission based on the description is illustrated in Figure 2.
Figure 1. Example of the transmission order description.
Figure 2. Transmission based on the description.
3 IMPLEMENTATION OF TRANSMISSION ORDER CONTROL
In this section, we discuss how we can implement the transmission order control.
3.1 Serialization on TCP Connection
In [3], it has been shown that the properly implemented HTTP/1.1[2] always outperforms HTTP/1.0 and dramatically reduces Internet traffic because of the introduction of persistent connections and pipelining. Furthermore, since it is difficult to synchronize the transmissions on multiple TCP connections, we decided to use a single connection to implement the transmission order control. In order to transfer multiple inline objects over a single TCP connection with the specified order, we must rearrange the bytes of the inline objects. We call such a rearrangement the transmission serialization.
Figure 3 illustrates the way to serialize the transmission of inline objects in which the transmission order is specified. A parallel transmission is emulated by subdividing the transmission of the contained elements into multiple equal-size pieces and transmitting them alternately from the front. The number of subdivided pieces is the slice value which is specified as an attribute of the par element. Note that although we assume that the slice value is specified by content authors, it might be better to adaptively determine the slice value according to the display refresh frequency of the web browser or the network bandwidth of the client. For example, it makes no sense to set a large slice value if the web browser does not refresh the display so frequently during the transmission. On the other hand, it is considered effective to set a large slice value when the network bandwidth between the server and the client is narrow.
Figure 3. Transmission serialization.
3.2 Transmission Order Control using HTTP/1.1
In order to realize the serialized transmission of inline objects, we can employ range requests (also known as partial GET) of HTTP/1.1. In the case that we employ range requests of HTTP/1.1, there is no need to change the server and only the web browsers need to be extended to understand the specification of the transmission order and issue range requests to the server. The interaction between the web browser and the server is depicted in Figure 4. First, the browser sends a request for an HTML document to the server as usual and receives the response. Then it parses the received document to extract the specification of the transmission order of inline objects. Since the file size of each inline object is required to issue range requests, the browser then sends pipelined requests for getting the file size of each inline object using the HEAD method. After receiving the file size of every inline object, the browser performs the transmission serialization and issues a number of range requests using pipelining to get the inline objects.
Although this mechanism does work, the overhead is not negligible in the case that the specification contains parallel transmissions. In that case, the browser needs to learn the file size of every inline object to perform the transmission serialization. In addition, the total size of range requests becomes large in proportion to the slice value.
Figure 4. Transmission order control using HTTP.
3.3 Transmission Order Control using HTSP
In order to reduce the overhead, we propose a new protocol, HTSP (Hypertext Streaming Protocol), to realize the transmission order control of inline objects. The new method, MGET, is introduced in HTSP to retrieve multiple objects with specified order by a single request. The MGET method specifies the target objects and their transmission order in the form of a transmission scenario. The transmission scenario is a simplified version of the transmission order description.
The following transmission order description is converted to a transmission scenario ["A",<"B","C">]10. The brackets ‘<>’ mean the sequential transmission and ‘[ ]’ mean the parallel transmission. The value is associated with the slice value in the par element.
<par slice="10">
<xfer object="A"/>
<seq>
<xfer object="B"/>
<xfer objcet="C"/>
</seq>
</par>
The following transmission order description is converted to a transmission scenario <"A"(30%),"B","A"(rest)>.
<seq>
<xfer object="A" volume="30%"/>
<xfer object="B"/>
<xfer objcet="A" volume="rest"/>
</seq>
Figure 5 shows the HTSP request message corresponding to the transmission order description in Figure 1, and an example of the corresponding response message is shown in Figure 6. In both messages, there are two kinds of headers. One is the common headers which describe the object-independent information such as Connection, User-Agent, Date, and Server. The other is the peculiar headers. Each line of the peculiar headers describes meta information on one object such as id, cn (Content-Name), in (If-None-Match), cl (Content-Length), ct (Content-Type), and sl (Status-Line). These peculiar headers have the same semantics as the headers in HTTP/1.1. However, we employ compact representation in order to reduce the overhead caused by these header fields.
Figure 7 illustrates the interaction between the web browser and the server when we use HTSP. The differences appear in the phase of requesting inline objects. First, there is no need to get the file size of each inline object. Instead, the browser converts the transmission order description extracted from the HTML document into a transmission scenario, and sends an MGET request message along with it. The server then performs the transmission serialization based on the transmission scenario, and sends the serialized body with headers including the file size of each inline object in the scenario. When the browser receives this response message, it learns the file size of each inline object from the headers and performs the transmission serialization in order to recognize how the response body has been serialized.
If the client's browser has local cached copies of some of the requesting inline objects, this mechanism still works well. It only needs to indicate the identification of each cached copy in the peculiar headers of the MGET request. The server then responds with the transmission body from which the valid objects have been left out.
Figure 8 shows the interaction in the case that object A, B and C are cached in the client, in which A is valid while B and C are no longer valid. How the valid cached object is presented on the browser is determined by the value of the cache attribute of the dto element.
Figure 5. HTSP request message.
Figure 6. HTSP response message.
Figure 7. Transmission order control using HTSP.
Figure 8. Interaction in the case of using cache.
4 EXPERIMENTS
4.1 Protocol Overhead
In order to make a comparison of the performance of the proposed protocols, we implemented an HTSP server by extending the W3C Jigsaw 2.02 web server [7] and also implemented a simple client which supports the transmission order control. In the experiments, we used a web page which contains seven inline images with the total data size of 125 KB. The transmission order has been specified so that the seven images are transmitted in parallel. We varied the slice value from 1 to 20 while we measured the round-trip time (RTT) for each of the following three methods: normal GET in HTTP/1.1 without the transmission order control, partial GET in HTTP/1.1, and MGET in HTSP.
Figure 9 shows the evaluation result when the client accesses the Internet from home using 56kbps modem. This result shows that the partial GET method has much overhead as the slice value increases. On the other hand, the RTT for the MGET method is almost equal to the RTT for the normal GET method. This result indicates that we can realize the transmission order control without much overhead.
Figure 9. Slice value vs. RTT.
4.2 Reduction of User-Perceived Latency
In section 1, we have indicated that we can reduce the user-perceived latency by using the transmission order control mechanism. Here, we try to quantify the latency reduction.
We used a top page of a computer company for this experiment. This page consists of an HTML file with the data size of 17 KB and 49 inline images with the total data size of 38 KB. We specified the transmission order so that 12 images used in links are first transmitted in parallel. In order to quantify the latency reduction, we compared our proposed mechanism and the existing transmission mechanism on the time to complete the transmission of these 12 images. We used Internet Explorer 5.0 which is one of the most popular web browsers as the existing transmission mechanism.
Figure 10 shows the measurement result when the client accesses the Internet using 56kbps modem. Note that Internet Explorer uses two TCP connections to get inline objects with HTTP/1.1 and it does not support pipelining. This result shows that our proposed mechanism can complete the transmission of the link images 4.3 seconds earlier than the existing transmission mechanism. Of course, the amount of the latency reduction may change every time we try to download the page depending on several factors such as the degree of network congestion and the server load. Our proposed mechanism, however, can guarantee that inline objects are transmitted in the same order in any situation, while the existing mechanism can not.
Figure 10. Reduction of user-perceived latency.
5 CONCLUSION
In this paper, we proposed a page transmission mechanism which allows content providers to control the transmission order of inline objects in WWW pages. The new protocol, HTSP, was designed to realize the ordered transmission of inline objects. We are now implementing a web browser which supports the proposed mechanism. We believe that the proposed mechanism is promising for effective web page publishing.
One problem of our proposed mechanism is that content providers must specify the transmission order of inline images for every page. In other words, whether our proposed mechanism will succeed or not depends on how easily content providers can specify the order. Therefore, we are also developing a web page authoring tool equipped with a transmission order editor and a transmission order previewing function. The editor will provide several "transmission order templates" which represent preference of the transmission order. By applying these templates to web pages, content providers will be able to specify the transmission order effectively and efficiently.
Since current version of HTSP does not support proxies, we must extend it in the future. We also plan to integrate the proposed mechanism with the transmission time control mechanism proposed in [1].
ACKNOWLEDGMENTS
This research was supported by “Research for the Future” Program of Japan Society for the Promotion of Science under the Project “Advanced Multimedia Content Processing” (Project No.JSPS-RFTF97P00501).
REFERENCES