Behavior of the Cache Server 
Starting of the Cache PUT Server
The Cache Server(sl_cache) 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
When the Relay Server (sl_relay) is started with a -cs, -cp or -cg option, TCP connections are created by Cache Server (sl_cache) 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) as the UDP Relay Processes are started.
When sl_relay 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, 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
It waits for a moment.
