spec-protocol-2PhW

Protocols: Two-Phase Warp protocol


This is still work in-progress.

The Two-Phase Warp protocol (2PhW) is just the Two-phase Commit for transactions processing, with an added negotiation period and a context switch.

Overview

The protocol is called a "warp", because it is assumed that the player will be crossing the bounds of time and space, whereas a "teleport" would only cross the bounds of space.

For 2PhW, the "Query to Commit" is called a "Warp" message; the "Vote YES/NO" is called "Ack[Warp]"; the "Commit/Abort" message is called "Engage" (yes, a Picard reference); and, the final "Acknowledge" is called "Ack[Engage]".

The sequence diagram is as follows:

sequence 2PC Warp

The coordinator can broadcast a "Query to Commit" to one or multiple participants (via IPSME). The coordinator then waits for replies to the broadcast (possibly multiple) and then chooses one to reply to, with a "Commit" or "Abort" message. It is not expected that the participant place the player in world, but the participant collects all data and prepares to do so.

The section before the "Commit" or "Abort" message has been sent is called the negotation section. Since the coordinator knows the destination it can preemptively starting broadcasting out assets for that destination or it can wait until it has received a "Vote YES" from the desired participant. The worst case here is that the preemptive sending is in vain because no viable participant responded. Each asset must be followed by an acknowledge which delays the coordinator and participant from timing out. Once the coordinator is convinced that all assets have been received along with the "Vote YES", it can send out the "Commit" message. An "Abort" can be sent at any time after the initial "Query to Commit".

As soon as the participant receives "Commit", the participant is in control of the player and the context can be switched from coordinator to participant. The participant sends an "Acknowledge" back to the coordinator after the context switch. It must be ensured that the context did switch before the "Acknowledge" is processed by the coordinator. When the coordinator receives the "Acknowledge", the player can be safely removed from the world and the world optionally shutdown.

"Commit" can not be used to trigger the context switch unless it can be guarenteed that "switch to Participant" is processed, if the "Commit" is processed by the participant. If such a guarantee can not be made, then it is possible that the switch happens when the "Commit" fails causing a switch to the participant when the participant hasn’t been notified to take control of the player. "Acknowledge" can not be used to trigger the context switch, because the coordinator might disconnect before the switch.

Failures

  • lost "Query to Commit": no reply from participants, the connection times out;
    the player remains in coordinator world

  • coordinator or participant failure during negotiation: warp transaction is aborted

  • lost "Commit": coordinator can attempt a resend and hope the participant doesn’t timeout, otherwise it is identical to "Abort"; player remains in coordinator world.

  • lost "switch to Participant": resend "switch to Participant", with a timeout on the player being idle causing the world to shutdown; player remains in coordinator world.

  • lost "ACK [switch]": resend "switch to Participant", with a timeout (that should not occur) on the player being idle causing the world to shutdown; control of player now in participant world.

  • lost "Acknowledge": resend the "Commit", with a timeout on the player being idle causing the world to shutdown. If the context never switched the player can just resume, otherwise the timeout will cause coordinator world to shutdown.

Short circuit

The Warp is sent out, but with a flag that the Warp will not be Engaged (committed); the destination sends an ACK, but then the algorithm ends. A short-circuit might be useful in a web environment to simulate HTML links.

Multiple Src/Dest Matching

If there are multiple sources and multiple destinations, how do we make sure that each source is served by a destination? The 2PhW protocol can be used with a variation of the Gale–Shapley algorithm or National Resident Matching Program.

  • Initialization: each source holds an empty list of unknown number of dest

  • Warp: each source broadcasts Warp; each destination will receive multiple warps; generated a pref list;

  • (*) Each destinsation will select and ACK one Warp (DO NOT abort the rest)

  • Each source

    • receives (possibly multiple) ACKs; chooses and Engages one destination, Aborts all the rest

    • (can possibly track how many destintations there are)

    • possibly didn’t received an answer from some destinations

  • destintations:

    • that received an Engage, Aborts all rest of the warps

    • sees an Engage corresponding to an open Warp source on the list, Aborts that source

    • that received an Abort, repeat at (*)

Schema

Msg2PhW

{
	"$id": "validate_Msg2PhW",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type" : "object",
	"required" : ["2PhW"],
	"properties" : {
		"2PhW" : {
			"type" : "string",
			"pattern": "0\\.7"
		}
	}
}

MsgWarp

{
	"$id": "validate_MsgWarp",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type" : "object",
	"required" : ["warp"],
	"properties" : {
		"warp" : {
			"type" : "object",
			"required" : ["user", "hyperport"],
			"properties": {
				"ttl_msec" : {
					"type" : "integer"
				},
				"instantaneous" : {
					"type" : "boolean"
				}
			}
		}
	}
}

MsgEngage

{
	"$id": "validate_MsgEngage",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type" : "object",
	"required" : ["engage"],
	"properties" : {
		"engage" : {
			"type" : "object",
			"required" : ["user", "hyperport"]
		}
	}
}

MsgOptions

{
	"$id": "validate_MsgOptions",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type" : "object",
	"required" : ["options"],
	"properties" : {
		"options" : {
			"type" : "object"
		}
	}
}
{
	"$id": "validate_Options_delay",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type" : "object",
	"required" : ["ttl_msec_incr"],
	"properties" : {
		"ttl_msec_incr" : {
			"type" : "array",
			"items": {
				"type" : "integer"
			}
		},
		"reason" : {
			"type" : "string"
		}
	}
}