![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2025-04-15T05:09:15+00:00","default:iseki","iseki") **Behavior of the Cache Server [#b86c7ba2] *** Starting of the Cache PUT Server [#n802464e] The Cache Server([[sl_cache>sl_cache (E)]]) forks a process called the Cache PUT Server at start up. The Cache PUT Server only functions to save of texture data to the database.~ Consolidating the saving of all cache data in single Cache PUT Server is done for two reasons. +To avoid the problem of facing a file lock when data is saved. If only one process is involved in writing data there is no problem managing file locks. +It is assumed that only localhost will connect with the Cache PUT Server. As a result, some level of security is achieved. *** Negotiation with UDP Relay Process [#p45034e3] When the Relay Server ([[sl_relay>sl_relay (E)]]) is started with a ''-cs'', ''-cp'' or ''-cg'' option, TCP connections are created by Cache Server ([[sl_cache>sl_cache (E)]]) for each UDP Relay Process. When the Cache Server receives a connection from the UDP Relay Process it forks a new Control Process. The Control Process then negotiates with the UDP Relay Process, exchanges connection password and a port number. ~ Therefore, the same number of Cache Control Processes for the Cache Server([[sl_cache>sl_cache (E)]]) as the UDP Relay Processes are started. When [[sl_relay>sl_relay (E)]] is started with ''-cs'' or ''-cp'' option (when PUT is effective), the Cache Control Process forks the Relay Process to Cache PUT Server. This process receives texture data from [[sl_relay>sl_relay (E)]], and forwards it to the Cache PUT Server. The Cache Control Process then enters a loop and waits for a data request from the UDP Relay Process. *** Response to request [#c92ce9c0] It waits for a moment.
