[sldev] LLCircuit removing the current sim without warning.

John Hurliman jhurliman at wsu.edu
Wed Mar 28 19:46:35 PDT 2007


Tateru Nino wrote:
> What would the chances be, do you think, of the primary sim sending a 
> secondary authentication cookie or caps string to the client in case 
> they lose touch?
> The client could send it as a 'Remember me? Could I have a replacement 
> circuit?' to the primary sim. If the primary sim is toast, of course, 
> bets are off. Reissue every 30-60mins, expire every 60-90.
>
> Daft idea?
>
> John Hurliman wrote:
>> Erik Anderson wrote:
>>>
>>> On 3/26/07, *John Hurliman* <jhurliman at wsu.edu 
>>> <mailto:jhurliman at wsu.edu>> wrote:
>>>
>>>     Erik Anderson wrote:
>>>     > From a user perspective I have had these problems quite often,
>>>     usually
>>>     > with the main client and with the minimum amount of RAM (i.e. hd
>>>     > thrashes and when it comes back I'm not there anymore).  Any way
>>>     for
>>>     > the circuit to reconnect somehow, rather than forcing the user
>>>     to relog?
>>>     >
>>>
>>>     In short, no. The simulator has most likely dropped you and you
>>>     need to
>>>     go through the entire login sequence again.
>>>
>>>
>>>
>>> Hmm, going through the wiki auth quickref, looks like the primary 
>>> sim acts as the agent's advocate to create new circuits, so you 
>>> wouldn't be able to reconnect to the primary sim (because you have 
>>> no advocate)
>>>
>> Right.
>>
>>> What about secondary circuits?  I've also been redmapped a number of 
>>> times when the sim has unexpectedly gone down, is it possible to 
>>> shove an agent into a neighboring sim if you still hold a valid 
>>> circuit?  Or does that require cooperation from the primary sim as 
>>> well?
>>
>> If you are talking about losing the connection to a neighboring sim 
>> and reestablishing that, it's the grids problems. Your current 
>> simulator will tell you to establish connections to neighboring sims 
>> by sending an EnableSimulator packet, so it is the duty of the grid 
>> to realize you have lost the connection to a neighboring sim, 
>> reconfirm internally that you are trusted, and send you an 
>> EnableSimulator packet again. Viewer doesn't need to worry about that 
>> other than blindly acting on EnableSimulator packets.
>>
>> If you were asking about hopping to a neighboring sim as a failover 
>> measure if you lose the connection to the primary sim, it won't work. 
>> Transitioning to a neighboring sim requires a CAPS call to the 
>> current simulator which triggers a lot of backend negotiations 
>> between the current and target sim. Without an established connection 
>> to the sim you are currently occupying there's no way to move your 
>> agent. If your connection times out and the current simulator (and 
>> implicitly the grid) drops you, the best the viewer can do is inform 
>> the user what happened and allow you to login again. I think a 
>> precursor to this would be allowing the viewer to log out without 
>> completely exiting the application.
>>
>> John Hurliman 

Doubtful. SL runs on the concept of circuits, and you're talking about 
adding a packet that operates outside of the circuit realm, where anyone 
on the Internet would be able to send this packet to sims and they act 
on it. You could make the AgentID/SessionID required, but if the sim has 
disconnected you then your SessionID has probably already expired, and 
to fix it you would need old sessions to hang around longer. This could 
make logins slower in some cases. If my assumptions about how the 
backend works are correct, you're talking about changing the "still 
logging out, please wait five minutes" message to "please wait 60 to 90 
minutes, we're still waiting for you to potentially reestablish your old 
session".

Just log in again! If your cookie expires on a website, you log in 
again. If your IRC session times out, you log in again. If your 
connection to AIM/MSN/Yahoo/ICQ messenger times out, you log in again.

P.S. I hope I got the posting order right. We are going top-post, 
bottom-post, top-post, bottom-post right?

John Hurliman


More information about the SLDev mailing list