Behavior of Information Server 
Information Gathering Server
The Information Server(sl_info) forked one process that is called Information Gathering Server at first time. This is the same idea as Cache PUT Server of sl_cache.
The Information Gathering Server preserves information of SIM in DB as well as Cache PUT Server.
Consolidating the information of SIM in Information Gathering Server and preserving it have two reasons.
- To avoid the problem of the file lock when data is preserved. If the written process is only one, the problem of the file lock is not caused.
- It is assumed to be only localhost to connect it with Cache PUT Server. As a result, some security is secured.
The data of SIM preserved in DB is
- SIM Name. (32Byte)
- GUID of SIM. (40Byte)
- Region Handler. (8Byte)
- SIM's IP address. (Binary form. 4 Byte)
- SIM's access. (2Byte)
- State of data. (2Byte)
- X coordinate of SIM. (4 Byte)
- Y coordinate of SIM. (4 Byte)
- Update Time. (Linux Time. 4Byte)
At present, information on sent SIM is only information on SIM by which Viewer (avatar) did handshaking. Therefore, information on new SIM is never sent from avatar in the state that the limitation by the white list filter.
Because it is the following with the state that the limitation by the white list filter.
- As for SIM that can be visited avatar, only data exists in the data base and the SIM has been permitted by the white list.
- SIM that cannot be visited cannot obtain those information it is not to be able to do handshaking by it.
When you gather information on new SIM, avatar that doesn't limit by the white list must be used. The collection of infomation with sl_relay never does a special operation. Only avatar flies around of SIM that has not been visited, and information is sent to the Information Gathering Server automatically.
The Information Gathering Server gathers information on the user (avatar) who is using sl_relay besides SIM information (however, it is not preserved in DB). Gathered avatar information is as follows.
- Avatar Name
- Agent ID of avatar
- IP address of Viewer
- Name of SIM where avatar exists now
- Update time of information (Linux time)
It is not possible to get information about "Name of SIM where avatar exists now", if there is no data of the SIM DB.
When sl_info is started by -l option, information on gathered avatar is preserved in the specified avatar log file.~ Default is /var/sl_proxy/sl_info_agent.log.
Negotiation with sl_relay
Relay Server (sl_relay) is connected with Information Server (sl_info) on the way of login processing to Second Life when started with the option of -is or -wf. The Information Server that receives the connection from sl_relay forked Control Process. The Control Process negotiate with the UDP Relay Process, and exchanges connection password and each use port number is exchanged.
Therefore, the Control Process of the Information Server is started each avatar．
Afterwards, the Control Process of the Information Server forks the Relay Process where information is transmitted to the Information Gathering Server.
This process receives avatar and SIM information from sl_relay (Relay Controller), and forwards them to the Information Gathering Server.
The Control Process enters the loop state afterwards, and waits for the request of the (UDP/HTTPS) Relay Controller of sl_relay as a Tendering Server.
Information Tendering Server (Process)
The Control Process of the Information Server operates as a Tendering Server, after Control Process forks the Relay Process that transmits information to the Information Gathering Server.
The Tendering Server can offer the following information. But, in sl_relay of present version (1.5.1), the Tendering Server is used for search the white list only.
- Name of SIM corresponding to region handler
- Search of white list by SIM name (Is the SIM is included in the white list or not?).
- Search of white list with region handler (Is the SIM is included in the white list or not?).
Please refer to White List Filter.
