Client/Server Design for Fast Retrieval of Large Images on the Internet

Abstract

At the National Library of Medicine (NLM), an application-level technique for improving the transmission rate of large images across the Internet has been developed. Initial performance tests were conducted in 1994 and evaluation has continued with a series of tests conducted with cervical x-ray image files transmitted from Texas Tech University (Lubbock, TX), the University of Arizona (Tucson, AZ) and the NASA Lewis Research Center (Cleveland, OH) to NLM (Bethesda, MD). Statistics were collected to compare the observed transmission rate using the NLM technique versus conventional FTP transmission. On the links tested the average transmission rate using the new technique showed a consistent improvement over conventional methods, including improvement of two- to three-fold on the Tucson and Cleveland tests. Work is now under way to extend the initial implementation into a portable, robust technique. In this paper, we present high-level design concepts for the second implementation and provide results of the most recent tests.

1. INTRODUCTION

Timely delivery of large image files across the Internet is potentially important in medical applications. At the Lister Hill National Center for Biomedical Communications, a research and development division of the National Library of Medicine (NLM), an application-level technique for improving the transmission rate of large images across the Internet has been developed. NLM research into techniques for faster delivery of large images on the Internet is motivated by the need to provide access to large collections of archived images. Such collections include the DXPNET digitized xrays [1] collected as part of a nationwide health survey, and the MRI, CT, and digitized cryosection photography data associated with the Visible Human project [2]. The NLM technique incorporates the "multisocket" (MS) concept of file transmission, an experimental technique which attempts to use Internet bandwidth more efficiently by making more data available for transmission within a fixed time interval is done with conventional "single-socket" transmission. Conceptually, the method is

1. Break the data into segments;
2. For each segment, create (in software only) a separate logical communications stream, connected to the destination;
3. Use multi-tasking to send the segments as rapidly as possible;
4. At the destination, reconstruct the segments into their original form.

2. DESIGN

2.1 Fundamental concepts and terminology

A socket is a communications end-point (starting point or terminating point). A sending socket and a receiving socket together form a socket-pair which establishes a communications link. In this paper, a single socket-pair is referred to as single-socket communication; the use of multiple socket-pairs to transmit data is referred to as multisocket communication. The link established by a socket-pair is a logical connection or channel for transmitting data in a stream. Single-socket communication sends one data stream down one logical connection (one channel). Multisocket communication sends multiple data streams down multiple logical connections (multiple channels).

The problem we are addressing is fast data retrieval on the Internet. We frequently speak of the data to be retrieved as "the image" , although the technique we present applies to any type of bulk data retrieval. In single-socket communication, the server sequentially transmits the bytes of the image to the client: the image is treated by the application software as a single entity. In multisocket communication, the server breaks the image into segments, and sends each segment down its own assigned channel; the client receives the segments and reconstructs the original image. It is important to note that this image reassembly takes place at the application level and is independent of any packet processing at the TCP or lower network protocol level.

The concepts of single- versus multisocket communication are illustrated in Figure 1 and Figure 2. In Figure 1 a single-socket server (such as FTP) is transmitting images to two remote clients simultaneously. Conceptually, each image is sent across a single channel in one piece. (There is no concept, at the application level, of fragmenting the image.) In Figure 2 a multisocket server is transmitting images to two remote clients. Client 1 is receiving an image on three channels; the image has been divided into three segments, and one segment is coming down each channel. At the receiving end, Client 1 must use the segments, which may not arrive in the correct order, to reconstruct the original image. Simultaneously, the server is using two additional channels to transmit an image to Client 2, using two channels and an image divided into two segments for that transmission.

Figure 1.

Figure 2.

2.2 Initial multisocket implementation (MS1)

The initial implementation (MS1) of the multisocket algorithm was designed only to evaluate transmission rate performance. MS1 does not serve multiple clients simultaneously, nor does it provide support for an interactive client, such as the capability to specify at run-time the name of a file to be transmitted, to request transmission of more than one file without program re-execution, or to dynamically set and change the number of channels to be used for transmission; further, there is no recovery mechanism in the event that one of the channels fails to complete its transmission. (A detailed description of MS1 is given in [3].) However, the consistent successful experimental results of MS1 in improving transmission rate have motivated design work for a subsequent implementation (MS2), incorporating a practical level of flexibility and robustness.

2.3 Design considerations for MS2

Creating a new client/server communications application requires design of the protocol to be used, as well as design of the client and server modules themselves. We conceive of the protocol design as specifying the messages, perhaps with accompanying data, to be passed between the client and server, along with rules for how the messages are passed. Figure 3 shows the fundamental concepts underlying this design. The protocol supports all communications capabilities required by the user interface, as well as additional communications control capabilities required by the application, but not seen by the user, for error recovery, for example. The primary purpose of the client and server is to implement the protocol; however, other considerations, such as whether the server should support multiple simultaneous clients, also influence the design.

Figure 3.

The design issues we have examined can be categorized as multiple client support, interactive client support, server machine loading control, error recovery, and client factors affecting maximum image size and reconstruction speed. These design issues and related application capabilities considered are listed in Table 1, along with costs and benefits for including the capabilities in MS2.

Multiple Client Support Using FTP as a model, we can see that providing capability to support multiple clients simultaneously provides significantly increased system capability. ("I do not wait for your transaction to finish before I can get the server's attention".) The main cost is that the server must keep open a socket used only for low-volume transmissions, so that it will always be possible to contact the server without incurring a long delay. An indirect cost is that multiple simultaneous clients will increase loading on the server machine; this is addressed under Server machine loading control.

Interactive client support We consider capabilities to do file directory operations (change directory, show current directory, list files in current directory) to get file information from the server machine, to be essential for a practical file retrieval system. Similarly, the basic capability to request (at run time) a file with specified file name to be transmitted, and to enter a subsequent file retrieval request after the previously-requested file has arrived, is required. These capabilities are needed for direct user interactions and are likely to appear on any user interface. Also considered was capability for the client to get another file before previous transmissions are completed. If this client capability were directly available to the user, the user could retrieve multiple files simultaneously, each file coming down multiple channels from the server. However, the increased complexity required by the server and client logic could be high--the server would need to control multiple simultaneous transmissions to multiple simultaneous clients. Clients would need to receive and reassemble the image segments corresponding to multiple images. In addition, we must ask, is the capability provided of real use in a practical application?

Client capability to request a fixed number of channels for its use, as opposed to having the number determined by the server without client input, is a valuable tool for experimental work in assessing transmission rate performance as a function of number of channels used. Further, there is no known way to have the server automatically select the best number of channels to use. Whether this capability should be directly available to the user is an issue to be determined by further experience with the application. In any case, in our current design we let the server determine the actual number of channels used for any transmission: the server receives the client request for N channels and makes a best effort to grant the request, based on current loading on the server machine. Capability to modify the number of channels dynamically means that the client may request N channels for one file transmission; then, when that file is received, the client may request M channels for the next file transmission. This provides additional flexibility expected to be useful for experimental data collection. Each of the channel-related capabilities just discussed may be incorporated without substantially increasing the complexity of the server.

Server machine loading control and Error recovery are discussed under MS2 server design issues.

Client factors affecting maximum file size and reconstruction speed are discussed under MS2 client design issues.

Table 1. MS2 Design Trade-offs (*strong candidate for inclusion in design)

Design Issue/ Capability	Trade-offs		*
	Costs	Benefits
Multiple Client Support	---	Significant system capability	X
Interactive Client Support
Do file directory operations	---	Needed for practical sys.	X
Specify file name at run time	---	Needed for practical sys.	X
Get another file before prev. received.	Signigicant client/server complexity	Usefulness not assessed
Request N channels for client	Modest server complexity	Experimentally useful	X
Modify num. client channels	Modest server complexity	Experimentally useful	X
Server machine loading control
Do dynamic load nomitoring	Complex; method not clear	Better use of srvr resources
Use simple threshold on num of channels allowed	Requires stateful server to track number of channels in use	Straightforward implementation	X
Error recovery
Destroy failed channel and request new one.	More client/server complexity. Need stateful server to track process id's of channels	Single-channel failures will not cause the entire transmission to fail.	X
Client factors affecting maximum file size and reconstruction speed
Do all image reconstruction using shared memory	Image size limited to available shared memory	Faster image reconstruction speed	X
Use files to hold image segments and do reconstruction	Image sizes possible greater than available shared memory	Slower image reconstruction speed

2.4 MS2 server design issues

Comer [4] provides a scheme for classification of servers based on whether they are connection- oriented or connectionless, concurrent or iterative, and stateful or stateless. A connection-oriented server uses a connection-oriented transport protocol, such as TCP, rather than connectionless protocols such as UDP; a concurrent server provides services to multiple clients which appear simultaneous, while an iterative server serves clients in sequence (which allows the possiblity that a client making a long request may impede service to a subsequent client which only needs a short time on the server); and a stateful server maintains information about previous requests to the server, while a stateless server maintains no such information. A stateful server allows the possibility that the same client request made at two different times will not result in the same response from the server, since the response is a function of the client request and the server state. In this scheme, our server is connection-oriented (since the underlying transport protocol is TCP), concurrent (since we allow multiple client requests to be served simultaneously), and stateful. Stateful servers introduce more complexity into communications programming and maintenance. The programming logic to simply maintain the state information correctly may be significant, particularly for a concurrent server which supports simultaneous connections to multiple clients. In addition, provision must be made for the possibility of server or client crashes, which should not be allowed to corrupt the state information or exhaust the resources of the state table with connections which are no longer valid. These considerations notwithstanding, we have designed the server as stateful, for reasons explained below.

Server machine loading control For each channel used in multisocket transmission a new process (and socket) is created on the server machine. Since the server supports concurrent clients, each using multiple channels, the server needs to guard against consuming an unreasonable amount of the server machine resources; in particular, it needs to limit the number of processes created on the server machine. In the ideal situation, the server might perform dynamic monitoring of the server machine load, that is, whenever the server received a client request, it would inventory the server machine resources (available processes, sockets, etc.) and make a decision about whether it can satisfy the client request. Even though this might be a good way to take advantage of available server machine resources, it may have serious disadvantages. We would need to be able to continually assess, from application code, what the limits are on major system resources and how near we are to those limits. A simpler, workable approach is to have the server use a simple threshold to limit the number of channels simultaneously available. The number of processes created can be limited by maintaining a total count of channels allocated (cumulative across all clients) and rejecting any client request to allocate channels beyond a preset maximum. The need to maintain this count of allocated channels is the first reason to maintain state information. A second reason derives from considerations for error recovery.

Error recovery In case of failure to receive a transmission on a channel, it is desirable to be able to recover by requesting a retransmission of the affected data on a new channel; if that fails, we terminate with an advisory message to the user. In any case, we need to insure that the server process dedicated to the failing channel is destroyed; this can be accomplished if the server maintains process id information for each channel. When the client detects a failed channel, it can then request that the server close that channel and retransmit on a new one. When the server receives a request to close a channel, it uses the process id for that channel to destroy the associated process before creating a new process to handle retransmission over a new channel. The need to clean up server processes for failed channels, which implies the need to track process id's for channels, is another reason to maintain server state information.

State information is modified by the server as clients connect, disconnect, allocate channels, modify channel allocations, and request file transmissions. We conceive of the state information to be maintained as organized into (1) one parameter, the number of channels available and (2) a "Connection Table" which contains information specific to any particular connection, such as process id's for processes controlling that connection's transmission channels, and time of last communication from the client on that connection.

Effect of client crashes on server state information. The design provides for the server to maintain a timer which performs maintenance on the state information table on short time intervals. Using this timer, the server checks to see if the difference between current time and the time of last communication from the client has exceeded a preset threshold; if so, the server attempts to close the connection and removes all state information related to this client. This prevents crashed clients from perpetually consuming state information resources. In addition, the server uses the timer to check that the process id's in the Connection Table are valid, and nulls out id's for server processes which have terminated.

2.5 Multisocket client design issues

Client factors affecting maximum file size and reconstruction speed Unlike many client/server applications, MS introduces significant complexity in the client. This is due in large part because the client receives the transmitted image in segments, by separate client processes, which must cooperate to reconstruct the original image. MS1 provides capability to receive all the image segments into shared memory. A design issue for MS2 is whether to incorporate this same technique. Using shared memory gives the fastest image reconstruction time; however, it limits the size of the image which can be received to the amount of shared memory current available. On high performance client machines, with perhaps 100 MB of shared memory available, this may not be an issue. An alternative would be to provide capability to receive the image segments into files and to reconstruct the image from those files; this, of course, could be slower than using shared memory.

2.6 Protocol

The protocol design includes messages from the client to request connection opening/closing, request for N channels for multisocket data transmission, messages required for recovery from channel failure (namely, request to close a failing channel and request to allocate a new channel in its place), and file access messages designed similarly to FTP. For each client message, a corresponding server acknowledgement, advisory, and/or data transmission is made.

3. RESULTS OF INITIAL EXPERIMENTS

Recent experimental data collections testing the performance of MS1 in three Internet links have been conducted. Two of these links were also tested and reported on in [3]. The third link, from Lubbock to NLM is a new link for data collection. The recent tests compared transmission performance of FTP versus MS1, with MS1 using five channels (5-socket transmission).

Machines Used. In all transmissions, the NLM machine used was a Sun Sparc 10 running Sun Solaris 2.4. The transmitting machines were as follows:

a. Texas Tech Univ, Dept of Electrical Eng, Lubbock: Sun Sparc 10 running Solaris 2.3

b. Univ of Arizona, Dept of Computer Sci, Tucson: Sun Sparc 20 running Solaris 2.3

c. NASA Lewis Research Center, Cleveland: Sun Sparc IPX running SunOS 4.1.3

a. 0 - FTP from Lubbock; 10 - 5-socket from Lubbock; 3/3/95 - 3/27/95;

b. 20 - FTP from Tucson; 30 - 5-socket from Tucson; 3/3/95 - 3/27/95;

c. 40 - FTP from Cleveland; 50 - 5-socket from Cleveland; 3/11/95 - 3/27/95

Table 2. Summary of test results. Time measurements and statistics are in seconds.

Transmitting site	Type	Num of sample points	Minimum time	Maximum time	Median	Mean	Standard deviation
Lubbock	FTP	553	91	570	100	113	45
Lubbock	5-socket	545	61	207	66	69	14
Tucson	FTP	576	89	1100	120	150	101
Tucson	5-socket	541	37	361	47	55	32
Cleveland	FTP	383	56	1100	140	168	101
Cleveland	5-socket	400	38	403	73	81	38

Figure 4.

Figure 5.

Figure 6.

Figure 7.

Figure 8.

Figure 9.

Note that, for the Lubbock and Tucson links, 25 days of data was collected; for the Cleveland link, only 17 days of data was collected, due to an error in the collection process. Figures 4,6, and 8 show histograms of the observed FTP and 5-socket transmission times for each of the links. For Figures 5, 7, and 9 the observed transmission times are averaged for each collection hour throughout the days of collection. For example, Lubbock's observed 5-socket transmission times collected at 12:10 p.m. each day are averaged for the 25 days of data collection, and plotted at the 12:00 point. In all of the comparisons of FTP versus 5-socket performance, the FTP and 5-socket transmissions are treated as occurring simultaneously, even though the collections were made 10 minutes apart. The number of data points collected varies from case to case due to machine outages or transmission failures of indeterminate cause.

4. DISCUSSION

Results obtained from the recent test series continue to validate the MS method as an effective way to obtain faster transmission on the Internet. The speed-up ratios obtained by using MS on the latest series of tests are given in Table 3 below.

Table 3. Speed-up ratios: MS compared to FTP

	Mean FTP time/Mean 5-socket time
Lubbock	1.6
Tucson	2.7
Cleveland	2.1

Work still remains to be done to understand whether similar results are obtainable through using conventional single-socket transmission and the proper tuning of transmission parameters. Setting the TCP buffer sizes for the client and server send and receive buffers and direct setting of the TCP window have yet to be explored in depth.

5. SUMMARY/CONCLUSION

Overcoming transmission rate bottlenecks remains a problem for applications needing to send large images across the Internet. Experiments conducted between NLM and collaborators support the value of the multisocket technique as one way of obtaining faster transmission. Work is continuing to develop an effective design for producing a practical application based on the multisocket technique.

6. REFERENCES

1. G.R. Thoma, L.R. Long, L.E. Berman,"Design Issues for a Digital Xray Archive Accessed over Internet," In: W. Niblack R.C. Jain, ed. Proceedings of SPIE: Storage and Retrieval for Image and Video Databases II. San Jose, CA: 1994; Vol. 2185, pp. 129-138.

2. The Visible Human Project, National Library of Medicine Fact Sheet, April 1993, Bethesda, MD.

3. L.R. Long, L.E. Berman, L. Neve, G.R. Thoma, "An Application-Level Technique for Faster Transmission of Large Images on the Internet," Proceedings of SPIE: Multimedia Computing and Networking 1995, vol. 2417, February 6-8, 1995, San Jose, CA.

4. D.E. Comer, Internetworking with TCP/IP, Vol. III, Client-Server Programming and Applications, Prentice-Hall, Englewood Cliffs, NJ, 1993.