Ghosts... are real in VR. Ghost avatars are the result of unnoticed disconnections or errors in the code.
Most ghost problems originate in the world server. If a client (tourist and citizen browser or a bot) gets disconnected from the world server and the world server does not notice the disconnection because it has not received a disconnection message (this happens regularly with sockets), a ghost is born. The world server, to protect itself against ghosts, has a timeout mechanism: it will test the connection every so often, and if it finds that it is not responding, it will close it and terminate the ghost. Or at least, that is what it should be doing, it seems to be working properly. But ghosts could be detected much earlier.
If a client (browser, bot) notices that it is disconnected, it will usually try to reconnect. And here things can go terribly wrong on the world server, and it does (tested with build 57).
ActiveWorlds has certain rules imposed by the universe server, which can help to detect and remove ghosts at an early stage avoiding duplicate connections (i.e. a client present both as a ghost and as a valid connection), before the timeout mechanism is used. Three universe server rules are relevant here:
First case: suppose you suddenly got disconnected from the world, leaving a ghost there because the world did not detect the disconnection. The world does not yet know it is a ghost. You did not disconnect from the universe, so you keep your session number. Your browser detects you have been disconnected from the world, tries to reconnect, and succeeds. Here things go wrong: the world does not check that there is a ghost there with the same session number, allows you in without first killing the ghost. You are now there alive and as a ghost (until the ghost times out). The world server could and should have checked this, because rule number 1 says there can not be two entities with the same session number, so the older one on the server must be a ghost. Testing for duplicate session numbers would remove ghosts of citizens, tourists and bots.
Second case: suppose you are a logged in as a citizen and suddenly get disconnected from the world (again leaving a ghost) and from the universe. When reconnecting, you will first log into the universe, get a new session number (not the old one), and reconnect to the world. Since you have a new session number, the world server could accept you... but as you are a citizen, and the world knows which citizens are in there, it should test to see if your particular citizen number is already in the world. If it did that, it would discover the ghost, banish it, and let you in (rule 2). But it does not, it allows both you and your ghost to co-exist in the world, until the ghost times out. Testing for duplicate citizen numbers would remove these ghost citizens.
Third case: similar to the previous one (disconnected from world and universe and reconnecting), but you are a tourist. The world knows the names of all the tourists in there. It could check to see if your tourist name is there. If it is, it can kill your ghost and let you in (rule 3). But it does not bother. Testing for duplicate tourist names would remove these ghost tourists.
Ghosts of bots can only be detected and removed on entry if the live and ghost connections have the same session number (first case). And if clients do not reconnect, ghosts will only be detected after a while if the timeout mechanism works. So there is no fourth case in my examples.
The first case is severe. The world server, the browser and bots rely on unique session numbers to identify avatars. Duplicate session numbers confuse the applications and make them malfunction. This is the cause, for example, of the anomalies experienced by bots in Global Mode. An AvatarDelete for a duplicate session number can not be assigned properly to an entity, the same applies to all session number related events and methods, and many more anomalies occur. For example, I have noticed that a live duplicate's chat does not get broadcasted in some cases.
The second and third cases also cause confusion, although somewhat less severe.
When these bugs gets fixed, Avatar Delete events for the detected and terminated ghosts should be sent to clients before an Avatar Add event is sent for the new connection.
The three cases of duplicates presented here are due to poor coding in the world server and should be fixed, because they interfere severely with the working of world server and client applications. Other ghosts can be or are removed by the world server using timeouts. Not all ghosts can be banished instantly, but duplicate live/ghost connections that can be avoided (and are not in any case in the current world servers 57 and 64) can and should be fixed to do so.