Teleports - Revision history

Justincc at 23:43, 22 October 2013

2013-10-22T23:43:45Z

Justincc at 23:42, 22 October 2013

2013-10-22T23:42:46Z

Justincc at 23:25, 22 October 2013

2013-10-22T23:25:02Z

Show changes

Justincc: /* Failure summary table */

2013-09-18T18:30:06Z

‎Failure summary table

Justincc: /* Stage 2: Transferring */

2013-08-09T17:06:06Z

‎Stage 2: Transferring

Justincc: /* Stage 2: Transferring */

2013-08-09T17:05:43Z

‎Stage 2: Transferring

Justincc: /* Stage 2: Transferring */

2013-08-09T17:05:03Z

‎Stage 2: Transferring

Justincc: /* Steps */

2013-08-09T17:03:36Z

‎Steps

Justincc: /* Steps */

2013-08-08T16:34:07Z

‎Steps

Justincc: /* Steps */

2013-08-08T16:33:31Z

‎Steps

← Older revision		Revision as of 23:43, 22 October 2013
Line 34:		Line 34:
	[SimulationService]		[SimulationService]
	ConnectorProtocolVersion = "SIMULATION/0.1"		ConnectorProtocolVersion = "SIMULATION/0.1"
		+
		+	=References=
		+
		+	* [[Teleport Protocol]] - an extremely in depth look at the teleport protocol.

@@ Line 10: / Line 10: @@
 * Between different networks within the same grid (e.g. between simulators hosted on OSGrid).
 * Between different networks on different grids (i.e. Hypergrid teleport).
 If you want to know an eye-watering amount of nitty-gritty about how this works, then please see the [[Teleport Protocol]] page.

@@ Line 322: / Line 322: @@
   | Source simulator receives the initial TeleportLocationRequest UDP packet from the viewer but does nothing further || Viewer displays a filling progress bar with the message "Requesting Teleport...".  There is no cancel button.  Viewer gives up after 140 seconds and returns the user to their source region where they can act normally.
   |-
-  | Source simulator replies to the viewer with the TeleportStart UDP packet but does nothing further || Viewer displays a filling progress bar with the message "Requesting Teleport...".  There is a cancel button.  If the cancel button is clicked before the source simulator starts asking the destination simulator to set up agents then cancellation succeeds and the user can act normally.
+  | Source simulator replies to the viewer with the TeleportStart UDP packet but destination simulator does not accept the initial create agent request || Viewer is informed of reason for teleport failure and can continue on original region.
   |-
   | Teleport succeeds up until the point where the viewer tries to setup a connection with the destination simulator in the Transferring stage.  Either destination region cannot be contacted by the viewer or destination region could not reply to viewer (a common cause of this is network issues).  || Source simulator will cancel teleport after a 20 second delay.  In OpenSimulator 0.7.5, things should continue normally and the viewer able to see/cross into neighbours from the source region, do other teleports and even perform the same teleport later on if the destination region network issues are resolved.  Before 0.7.5 there may be problems with this process.

← Older revision		Revision as of 17:06, 9 August 2013
Line 265:		Line 265:

	==Stage 2: Transferring==		==Stage 2: Transferring==
		+	'''TODO: Detail the complicated arrangements to stop regions wrongly closing child agents where the simulator re-teleports within 15 seconds (the wait period before the original source region connection is closed.)'''
		+
	The teleport is now in flight. If it fails then cleanup takes significant steps and may not work anyway because the viewer has a different view of what happened - a view which unfortunately could be uncorrectable except by relog).		The teleport is now in flight. If it fails then cleanup takes significant steps and may not work anyway because the viewer has a different view of what happened - a view which unfortunately could be uncorrectable except by relog).

← Older revision		Revision as of 17:05, 9 August 2013
Line 73:		Line 73:

	==Stage 2: Transferring==		==Stage 2: Transferring==
−	'''TODO: Detail the complicated arrangements to stop regions wrongly closing child agents where the simulator re-teleports within 15 seconds (the wait period before the original source region connection is closed.)'''
−
	The teleport is now in flight. If it fails then cleanup takes significant steps and may not work anyway because the viewer has a different view of what happened - a view which unfortunately could be uncorrectable except by relog).		The teleport is now in flight. If it fails then cleanup takes significant steps and may not work anyway because the viewer has a different view of what happened - a view which unfortunately could be uncorrectable except by relog).

@@ Line 304: / Line 304: @@
 * C1, S, Meanwhile, the source region pauses (currently 15 secs) before possibly closing the old connection.  An earlier close can cause a viewer crash or place the avatar at an infinite position for a few seconds.
 ** C1A, S, However, if the ScenePresence.DoNotCloseAfterTeleport flag has been set, we do not close the connection.  This may have been set if the user immediately teleported back into a region which neighbours the original source region (and hence should retain the child connection).
-** C1B, S->SCh*, If the ScenePresence.DoNotCloseAfterTeleport flag has not been set, send '''CloseAgent''' messages to child regions to close their connections.  '''TODO: This may be a bug where we end up closing other child connections that should not close, for the same regions as given previously.  Possibly could resolve this by checking and resetting ScenePresence.DoNotCloseAfterTeleport in Scene.RemoveClient() instead the acd lock.  On furhter investigation, not possible since RemoveClient occurs well within LLClientView.Close().  May need to restructure code.''')
+** C1B, S->SCh*, If the ScenePresence.DoNotCloseAfterTeleport flag has not been set, send '''CloseAgent''' messages to child regions to close their connections.
 ==General notes==

@@ Line 281: / Line 281: @@
 * T1, S->V, The source sends the viewer a '''TeleportFinish''' Event Queue message.  This contains information about the destination simulator's IP:Port and it's capabilities URL.
 ** T1A, V->D, The '''TeleportFinish''' message sent to the viewer triggers it to send a '''UseCircuitCode''' UDP packet to the destination simulator in order to establish the connection.
-** T1B, D->V, The viewer creates the connection and sends back a PacketAckPacket back to the viewer.
+** T1B, D->V, The viewer creates the connection and sends back a '''PacketAck''' UDP packet back to the viewer.
 ** T1C, V->D, This viewer also sends a '''SEED''' capability request to the destination simulator.  The destination replies with all the capabilities that are available on that simulator.
 * T2, V->D, The viewer then sends a '''CompleteAgentMovement''' UDP packet to the destination on the newly established UDP connection.