# Reliable User Datagram Protocol as a Solution to Latencies in Network Games
## 3 RUDP Implementation in the Transport Layer to Handle Latency
### A Design of RUDP Architecture  
The core of this subject is compensating the negative characteristic of UDP, unreliability. However, the goal of this research is not just realizing the meritorious characteristics of TCP but also creating reliable data like TCP as well. The reliable characteristics of TCP compared to UDP can be summarized as follows. First, there are no data transformations. Second, there are no data losses. Third, data arrives in consecutive order. Achieving all these points for implementation is the core theme in designing and implementing RUDP. Some possible methods for this purpose are: first, for the prevention of data transformation, it seems suitable to insert an error code in advance and check the error occurrence incidents. Then, ignore error packets or request a re-transmission. It is possible to consider a method of recovering the errors by inserting a certain error-correction code, but this would also cause an unnecessary dissipation of bandwidth as the error rate in the UDP layer is actually very small. The negative characteristic related to data loss can be solved by persistently sending the undelivered packet until the opponent's acknowledgement packet arrives. It seems that this method has more merit in terms of processing difficulty or efficiency than letting the opponent transmit the packet-loss event packet, even if much dissipation of bandwidth is expected. For the sequential processing of data, it is possible to process the data by checking the sequence of arriving packets first and tentatively storing the data subsequent to the unarrived packet during the transmission; then, sending out all the data to the game after all the preceding lost packets have arrived. Thus, RUDP is quite effective for latency control. RUDP has a function of re-transmitting lost packets or receiving an acknowledgement packet. It is faster than TCP and utilizes UDP that guarantees packet deliveries with its convenient re-transmission structure. Nevertheless, RUDP is not a standard protocol provided like UDP or TCP. It has to be directly implemented in accordance with the protocol's specification or procured (i.e., separately offered in Software Development Kit (SDK). If it is possible to use the UDP implemented with the re-transmission function, the packets to be transmitted can be handled in the same way TCP does. That is, it becomes a protocol which can be used for any kind of game. RUDP can be a good alternative for UDP when the game requires faster response times and higher reliability as it guarantees re-transmission of lost packets and 'guaranteed-order packet delivery'. Such a kind of selective-repeat protocol performs reliable communications by confirming the successful delivery of transmitted packets and also by implementing the timeout function. RUDP has been specifically designed to guarantee normal data flow. Below, Figure 4 shows the architecture of RUDPWithin Figure 4 is a description of the service R UDP is offering. The two-way transmission process is carried out in the application layer where data is transmitted through a reliable channel. Figure 4 briefly describes the R UDP service implementation process wherein a sender and a receiver maintain a pre-defined window size (i.e., usually maximum size) to avoid any errors in the communication process occurring from packet loss incidents. Even if the data has been sent over an unreliable channel, a higher rate of successful delivery can be expected. The architecture involving both sender and receiver is discussed in the other sections of this chapter. In order to avoid a 'Deadlock' situation, the shared buffers were synchronized by employing the counting semaphores so that only a single thread can access the buffers each time. The respective window size (i.e., window sizes of sender and receiver) are traced consistently by observing the variables 'base' and 'next'.