Desktop presentation tool for e-learning support and the high-speed UDP datagram loss

Michal Kokorceny and Agata Bodnarova Faculty of Informatics and Management

University of Hradec Kralove Hradec Kralove, Czech Republic

michal@74.cz, agata.bodnarova@uhk.cz

Abstract—The aim of the Desktop-projector project is to create a software tool (application) for more effective teaching in computer classrooms, especially in cases, where classic projector can’t be used. The Desktop-projector is typically used for showing presentations or other activities carried out on the teacher’s desktop in other desktops. The teacher’s desktop is broadcasted to other computers on the local area network. The article describes the basic principles of the solution and the problems encountered during the development. It was concluded that the UDP datagram loss is not affected at the network layer or at the operating system, but at an application level.

Keywords—desktop; projector; UDP; data loss; high-speed data transfer

I. INTRODUCTION The concept of e-learning is often presented as the usage of

web based technologies or the Internet in the education process. This definition is particular. In generally, e-learning presents the usage of any information and communication technologies in the process of education.

The aim of the Desktop-projector project is to create software tool (application) for more effective teaching in computer classrooms, especially in cases where there isn’t a classroom or portable projector, or where it is needed to transfer images from different computers that can’t be operatively connected to the projector. This article presents a desktop-sharing tool, the Desktop-projector, which was created for the needs of our educational organization. Desktop-projector is a program for broadcast (transfer) of the desktop (screen) of one computer to other computers on the local area network (LAN). Desktop Projector is typically used for showing presentations or activities carried out with one computer to other computers (such as showing the teacher’s computer desktop to students). This article describes the basic principles of the solution, the problems encountered during the research, and their possible solutions.

Before the development of the Desktop-projector we tried to find and test another, already existing software products. The only similar software that has the required features and functionality is the TightProjector. This application is described and available at [9]. Detailed comparison with our application Desktop-projector was not possible. TightProjector software is

based on other principles, it contains a completely different configuration in relation to the problems covered in this article. Additionally, the application TightProjector wasn’t functional in the test environment in which our application, the Desktop-projector was tested and on which performance tests were carried out as it is described in the following chapters.

II. DESCRIPTION OF THE CURRENT SOLUTION The basic requirement is the ability of projection of one

computer’s desktop (screen) to desktops (screens) of other computers. Visual information is transmitted via LAN. One computer can be in the role of the visual information transmitter. The role of receivers is not limited; it is available for several PCs in the same LAN. Usually the number of simultaneous receivers is under forty. The real-time transmission of continuous video signal (streaming) is not required. The solution is based on the need of capture and transmission of the transmitter’s desktop to other computers desktops on the local network – this difference significantly affects the concept of the solution and the resulting application architecture.

The aim is to achieve as fast transmission as possible of visual information from the transmitting computer and then display on the receiving computers screens. The entire transfer of visual information, respectively the transfer of the changes in this visual information is not necessarily in real-time mode (it would be very CPU consuming and bandwidth consuming of the transmission channel), but be sufficient to meet the basic requirements for application carried out during the presentation of the activities on the computer. Sufficient speed can be regarded as our empirical experience showed, several frames per second (e.g., 3 to 5 frames per second).

Of course it is very inefficient solution, which carries out the whole screen without using compression. Transfer of the entire screen is not possible in real time even when compression is used. The usage of any sufficiently effective compression algorithm (e.g., lossy JPEG compression) would be greatly encumbered by the CPU, which would be impossible to achieve the desired transfer rate and at the same time there was a decrease in performance computers broadcasting.

For these reasons it was chosen the following solution: the entire screen was divided into equal blocks – actually tested

978-1-4673-1678-1/12/$31.00 ©2012 IEEE 21

block sizes from 12x12 pixels to 48x48 pixels. The results of the impact of different block size screen on the transmission quality will be described later. After dividing the screen, changes in individually blocks are detected. Only changed blocks, not the entire screen, are transferred. This solution is effective in case of bandwidth consumption on the local network. The disadvantage of the solution is higher CPU consumption of the transmitter due to the need of continuously changes detection.

The transmission process is implemented in the current solution as follows:

• Get full-screen image.

• Divide the screen into blocks.

• Detection of changed blocks.

• Compression of changed blocks (currently RLE(Run Length Encoding) algorithm, we plan to use ZLIB compression).

• Transmission of the changed blocks using UDP (User Datagram Protocol) datagrams.

• Pause for a defined time period (sleep) and then repeat the process.

To increase the efficiency of the process of the broadcast transmission, it is divided into two separate threads, where the first thread provides a full screen capture and detection of changed blocks and the second thread provides datagrams sending via the UDP protocol. Both operations – screen capture and datagrams sending – are time consuming, so the division into two separate threads allows better usage of resources. The operations don’t block each other waiting for their completion.

The process of receiving is relatively trivial:

• Receiving UDP datagram.

• Decompression of the block of the screen.

• Display the block of the screen.

• Repeat the process.

In case of the requirement for a large number of simultaneous receivers at the same time, as the image information transfer protocol, the UDP datagram broadcasting transport layer protocol was chosen – it is not possible to use the TCP (Transmission Control Protocol) transport layer protocol. Another option is in the case of UDP transport layer protocol, to use multicast UDP datagrams, but it is based on similar principles as broadcast datagrams. The selection does not affect the overall solution and the described problems.

The current version of Desktop-projector is designed as a standalone application on a Win32 platform in Delphi XE Professional. However the choice of the technology does not significantly affect the problems of implementation of this project, which are described in this article.

On the Figure 1, the Desktop-projectors welcome screen is shown. After launching the DesktopProjector.exe file, the welcome screen opens. The user is supposed to choose,

whether to be a receiver or a transmitter. In case of a transmitter, the desktop’s screen is transmitted. In the case of the receiver, the desktop’s screen of the transmitter is received and displayed.

Figure 1: The Desktop-projector's welcome screen

III. PROBLEM DEFINITION During the works on this project we were faced with

several complications. The most serious problem is the occasional UDP datagrams loss during the transmission of visual information. During the transfer of the image of the computer’s desktop screen some blocks don’t processed and remain in the old state – without redraw. In user perspective it is very unsuitable. The number of lost datagrams in this case is clear metric for quality evaluation of the solution. A key issue discussed in this article is the rate of UDP datagram loss in the rapid UDP datagram traffic. The aim is to identify the cause of the UDP datagram loss – which is quite difficult – and then make adjustments in the application to eliminate the problem or at least reduce.

Generally, the datagram loss problem may be caused both in the transmitter or receiver site and at different levels: at the network level, application layer level or at the level of operating system.

IV. PROBLEM SOLUTION The project passed through several major changes in the

solution during the development. The architecture of the software application was also changed. Overall this issue is in scope of further research and development.

As we said before, the first version of the Desktop-projector had significant UDP datagram loss. In user perspective, the solution wasn’t usable, the rate of loss depended on hardware performance.

After analysis, we concluded that the reason of the datagram loss on the application layer at the side of the receiver was found. For work with the network layer in Delphi most commonly Indy components are used, they support implementation of a wide range of protocols, including UDP [1]. The Indy UDP communication component is implemented so that during the datagram income, in the

978-1-4673-1678-1/12/$31.00 ©2012 IEEE 22

memory is dynamically allocated a buffer sized for storing the received data. The dynamic memory allocation is time consuming, and only one datagram at time is possible to process. The program was during the datagram process in blocking mode – any other incoming datagrams were discarded.

A similar problem of packet loss when rapid traffic is facing a number of other software applications is often caused by improper use of components working with the network layer.

We solved this problem in three steps:

• Instead of Indy component library the Windows Sockets API (WSA, Winsock) has been used, the MS Windows operating system interface to communicate on the network.

• For UDP datagrams receiving predefined size static buffers (instead of dynamic buffers) are used, which speeds up the operation. The datagram processing is less time consuming, the number of dropped datagrams is also fewer.

• Processes at the receiver were also divided into two separate threads – the first thread provides the receiving of UDP datagrams and stores them in the ring buffer, the second thread then collects the datagrams from the ring buffer, it provides the decompression and displays the visual information. This division into two threads significantly reduces the number of lost datagrams.

Another element that affects the rate of UDP datagram loss is the size of the transmitting and receiving buffer in the operating system (socket buffer). Tests haven’t show, that the size of the transmission buffer significantly impacts the data quality [2]. More important is set the receiving buffer at as highest value as possible [2] [3] [4]. If the receiver is blocked by the processed datagram, then the receiving buffer of the operating system is used to temporarily store received data – otherwise data are discarded. Here is the inadequate and ambiguous documentation from the manufacturers of operating systems. The maximum supported socket buffer size depends on the type of operating system [5], OS version etc.

It is also not clear what is the maximum buffer size that can be set on a particular system. Experimentally it was found that the Windows platform (tested 32-bit systems XP, Vista and 7) supports maximum buffer size 256 kB both for the transmitting and receiving socket buffer [5]. This capacity is several times smaller than the capacity required for the transfer of the entire desktop (screen). This leads to the conclusion that increasing the value of the receiving buffer can reduce the number of dropped UDP datagrams, but can’t completely eliminate this problem.

A very important parameter that affects the behavior of the system is the optimal screen’s block size setting. Actually tested block sizes are from 12x12 pixels to 48x48 pixels. As smaller the block screen is, as greater is the CPU load. On the other hand, larger screen blocks increase the network traffic, because in case of a small change (e.g. change of one pixel) the

whole block is necessary to transfer. The block size has also significant effect on the UDP datagrams loss rate. Theoretically, as larger UDP datagrams are transferred, as bigger the likelihood of loss is. This is due to the fact that large datagrams is necessary to fragment to a larger number of packets and then merge the income back into a single datagram (see Maximum Transmission Unit – MTU e.g. 1500 B for Ethernet) [6]. The partial loss of one packet then means the entire datagram loss, i.e. in our case, block of the sent screen. The Desktop-projector’s initially block size was set to 32x32 pixels, corresponding to the buffer size of about 3 kB (without compression). Subsequently, tests were performed with both smaller and larger screen-block sizes and the UDP datagram loss rate was monitored. Paradoxically, against initial estimates, the loss rate was lower in case of the larger sized UDP datagrams (in opposite to results of papers [2] [3]). This fact leads to the conclusion that datagram loss is not affected at the network layer or at the operating system, but at the application level. In the case of smaller number and larger size datagrams, the application has more time for processing and less datagram are lost in blocking mode.

V. PERFORMANCE TESTING During the development several performance tests in order

to obtain the optimal configuration values - especially to determine the optimal screen block size regard to the UDP datagrams loss and performance (speed) of visual data transmission between the transmitter and receiver were conducted. For these measurements 100Mbps Ethernet network with a simple L2 switch was used. The computers in the following configuration were used: CPU 2.4 GHz, 4 GB RAM, screen resolution of 1680x1050 pixels and OS Windows XP / Vista. The tests were used for different screen block sizes: 12x12, 16x16, 24x24, 32x32, 40x40 and 48x48 pixels. Application level measurements were performed on Desktop-projector receivers.

The first of the tests was focused on the UDP datagram loss detection dependence on the screen block size. The results of the experiment are shown in Figure 2. As already mentioned, in contrast to the results listed in articles [2] and [3], the UDP datagrams loss rate is reduced by increasing the size of IP datagrams. Interesting is a jump and the opposite trend of loss between the values of 16x16 pixels (14%) and 24x24 pixels (18%). This behavior was confirmed by repeated measurement. The size of a datagram in case of 16x16 pixel large block is 768 B, in case of 24x24 pixel block is 1728 B (without compression). It is because the 24x24 pixel large blocks datagram oversize the MTU. The Maximum Transmission Unit (MTU) is the maximum length of data that can be transmitted by a protocol in one instance. For example, the MTU of Ethernet (by default 1500B) is the largest number of bytes that can be carried by an Ethernet frame (excluding the header and trailer) out [10]. The 24x24 pixel large block’s datagram is divided into two packets, causing a greater loss of packets at the network layer.

However, by expanding the screens blocks, there is a gradual downtrend in the rate of loss - it confirms the hypothesis that the loss of datagrams occurs rather at the application layer than at the network layer.

978-1-4673-1678-1/12/$31.00 ©2012 IEEE 23

Figure 2: UDP datagram loss

The second test is then focused on the dependence of the visual data transmission on the screens block size. Results of the experiments are in Figure 3 shown. According to the assumptions found in articles [2] and [3], the data throughput between the transmitter and receiver increases with the increasing size of transmitted datagrams.

Figure 3: Data transfer performance

In the case of Desktop-projector we have reached the limit with screen block size 40x40 pixels and higher.

Based on the results of performance tests can be considered more appropriate to use larger values of screens block size. On the other hand, larger screens blocks load more traffic, because in small change (such as a change of one pixel) more data is required to transfer. Therefore it is necessary to choose a value that would ensure a sufficiently small datagrams loss and sufficiently large data throughput. Based on the results, the optimal value appears to 40x40 pixels.

VI. OPEN QUESTIONS As it was written before, issues in this project are

considerable scopes for further research and development. The following questions and challenges will be solved in the short and medium term horizon. Their answer will contribute the quality of the solution:

• Detailed analysis of influence of block size of the screen on the quality of transmitted data.

• What is the maximum size of the UDP datagram?

• What is the effect of setting different priorities to individual threads of processes of the transmitter and receiver?

• What is the impact of used compression algorithms (RLE, ZLIB ...)?

• What is the effect of setting the DF (Do not Fragment) bit, how it is supported on different platforms [5]?

• Is it appropriate to use the overlapping mode for receiving of datagrams?

It is also expected that during the further development new problems associated with new questions will be necessary to solve.

VII. CONCLUSION In this article we have introduced an e-learning tool – the

Desktop-projector. This application is used for transmission (transfer) of the desktop (screen) of one computer to other computers on the LAN. In addition to the basic principles of the solution, the article describes the main problems encountered during the research. Possible solutions were also presented. The most serious problem is the occasional UDP datagram loss during the rapid visual information transmission. Several blocks are not processed and remain in the same state – without displaying the changes. Identification the cause(s) of UDP datagram loss is highly problematic, even after several months of development we failed to find the final and reliable solution.

In further development of the Desktop-projector we plan focus on the following areas:

• The primary goal is the improvement of the quality of transmitted image information and reduction of the UDP datagram loss using different hardware and network elements.

• Optimization for usage in wireless (WiFi) networks [7].

• Ability to work with multi-monitor systems.

• Improved integration with other systems, especially e-learning systems.

• Implementations of the IPv6 protocol [8].

• Implementations for other platforms – currently the implementation is only for Win32 platform.

ACKNOWLEDGMENT This work was supported by the project No. CZ.1.07/2.2.00/28.0327 Innovation and support of doctoral study program (INDOP), financed from EU and Czech Republic funds.

REFERENCES

[1] Internet Direct (Indy), TIdUDPServer.OnUDPRead, URL:<: http://www.indyproject.org/docsite/html/frames.html?frmname=topic&frmfile=index.html>[cit. 2012-9-5]

[2] Y. Gu, R.L. Grossman: Optimizing UDP-based Protocol Implementations, in Proceedings of the Third International Workshop on Protocols for Fast Long-Distance Networks (PFLDnet 2005), Lyon, France, 2005.

978-1-4673-1678-1/12/$31.00 ©2012 IEEE 24

[3] H. Sawashima, Y. Hori, H. Sunahara, Y. Oie: Characteristics of UDP Packet Loss: Effect of TCP Traffic, in Proceedings of the INET’97, Engineering 3-1, 1997.

[4] Y. Gu, R.L. Grossman: Using UDP for Reliable Data Transfer over High Bandwidth-Delay Product Networks, in The International Journal of Computer and Telecommunications Networking archive, Volume 51, Issue 7, New York, USA, 2007, pp. 1777-1799.

[5] Setsockopt function: Microsoft, 2012, URL:<http://msdn.microsoft.com/en-us/library/windows/desktop/ms740476(v=vs.85).asp>, [cit. 2012-9-5]

[6] J.Y. Lee: Optimum UDP packet sizes, in ad hoc networks, in IEICE Trans Commun, Japan, 2002.

[7] G. Xylomenos: TCP and UDP performance over a wireless LAN, in Proceedings of the INFOCOM '99 – Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies, New York, USA, 1999.

[8] E. Gamess, R. Surós: An upper bound model for TCP and UDP throughput in IPv4 and IPv6, in Journal of Network and Computer Applications archive, Volume 31, Issue 4, London, United Kingdom, 2008, pp. 585-602.

[9] TightProjector Software URL:<http://www.tightvnc.com/projector/> [cit. 2012-9-5]

[10] MTU manipulation URL:<http://packetlife.net/blog/2008/nov/5/mtu-manipulation/> [cit. 2012-9-5]

978-1-4673-1678-1/12/$31.00 ©2012 IEEE 25