[sldev] LLCircuit removing the current sim without warning.

Tateru Nino tateru.nino at gmail.com
Wed Mar 28 20:21:49 PDT 2007



John Hurliman wrote:
> 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".
I was thinking 60-90 mins to more or less reduce sim workload (at the 
expense of a little more store) - any interval would work so long as 
it's neither spammy nor arduous. Here, we're more talking about a 
secondary login that reconnects a session that (hopefully) still already 
exists, rather than a full login and a new session. The power flutters, 
my cable modem has a cow for just long enough - My session is still 
there, if only I can reestablish a circuit to the simulator.
>
> 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.
>
Well, I think the situation I'm primarily thinking about here is where 
the client loses the circuit but the primary sim hasn't lost the 
session. Unless you move or try to talk or (eventually) redmap, there's 
no sign of it at your end, and as far as everyone else is concerned, 
you're still logged in and standing there (or stuck typing).

It's a situation I see more than a dozen times per day, with some people 
periodically typing 'x' or 'test' in chat to see if they're still 
connected to the primary simulator. I can't help thinking there's a 
better way of dealing with the broken connection than a relog. The 
client takes an unusually long time to terminate after loss-of-circuit. 
Sometimes as much as ten minutes. Five minutes or more before you (the 
human) notice you've lost your circuit, up to ten minutes to log out, 
several minutes to load the client and reconnect. Find out that your 
meeting is over. I'd *love* to get the pain taken out of that cycle.
> P.S. I hope I got the posting order right. We are going top-post, 
> bottom-post, top-post, bottom-post right?
I think it's bottom-top-bottom-bottom-top. Blame it on the bossa nova. 
Maybe our best option would be a posting order in quickstep. Do you tango?

-- 
Tateru Nino
http://dwellonit.blogspot.com/



More information about the SLDev mailing list