Subway Synchronization Protocol
Transit Rider Protocols Working Group J. Kaufman
Request for Comments June 2015
Category: Standards Track
Subway Synchronization Protocol -- SSP 1.0
------------------------------------------
Status of this Memo
This document specifies a standards track
protocol for the Transit Rider community, and
requests discussion and suggestions for
improvements. Please refer to the current
edition of the "Transit Rider Official Protocol
Standards" for the standardization state and
status of this protocol. Distribution of this
memo is unlimited.
Abstract
The Subway Synchronization Protocol (SSP) is a
single-purpose stateful user-level protocol for
distributed coordination among convergent
parties of subway riders.
SSP has been in daily use since 2014. This
specification defines the protocol referred to
as "SSP 1.0".
Table of Contents
1 Introduction ..............................2
1.1 Purpose ................................2
1.2 Requirements ...........................2
1.3 Terminology ............................2
1.4 Notation ...............................3
1.5 Overall Operation ......................3
2 Structure .................................4
2.1 Notification ...........................4
2.2 Acknowledgement ........................4
2.3 Resending ..............................4
2.4 Exceptions .............................4
3 Notifications .............................4
3.1 Carriage Designation ...................4
3.2 Stop Arrival ...........................5
4 Handling Notifications ....................5
5 Merging ...................................5
J. Kaufman Standards Track [Page 1]
---------------------------------------------------
RFC Subway Synchronization Protocol June 2015
1 Introduction
1.1 Purpose
The Subway Synchronization Protocol (SSP) is a
single-purpose stateful user-level protocol for
distributed coordination among parties
attempting to converge on the same subway
carriage.
1.2 Requirements
The key words "MUST," "MUST NOT," "REQUIRED,"
"SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT,"
"RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119.
1.3 Terminology
This specification uses a number of terms to
refer to the roles played by participants in,
and objects of, the SSP communication.
party
A group of one or more people traveling as a
unit.
communicator
The member of a party responsible for
inter-party communication. The method of
selection is left unspecified by SSP, but
each party MUST have exactly one
communicator.
carriage
A vehicle for the transportation of parties.
station
A place where parties may enter or exit a
carriage.
train
An ordered series of carriages moving as a
unit between stations.
message
A sequence of human-readable characters
composed by a communicator.
J. Kaufman Standards Track [Page 2]
---------------------------------------------------
RFC Subway Synchronization Protocol June 2015
initiator
The communicator of the party that boards the
train first.
joiner
The communicator of the party that attempts
to, at a subsequent station, board the same
train and carriage as the initiator.
notification
A message sent from the initiator to the
joiner to assist the joiner in their task.
acknowledgement
A message sent from the joiner to the
initiator confirming receipt.
1.4 Notation
When referring to a message, the message
contents are set off in square brackets. For
example, [example message]. The square brackets
are notation only, and not part of the message.
1.5 Overall Operation
The SSP protocol is a stateful protocol with a
request-acknowledgement structure. By sending a
series of notifications an initiator can provide
a joiner with sufficient information that the
joiner can arrange for the parties to merge.
Prior to use of SSP the communicators MUST have
agreed through some out-of-band method on which
stations the initiator and joiner will board the
train. These stations SHOULD have at least two
other stations between them for reliable
operation, and MUST have at least one.
SSP communication usually takes place over Short
Message Service (SMS), but other transports can
be used. The transport is not required to be
reliable, but the correct operation of this
protocol depends on low message loss and latency.
J. Kaufman Standards Track [Page 3]
---------------------------------------------------
RFC Subway Synchronization Protocol June 2015
2 Structure
2.1 Notification
At several points described below, the initiator
sends a message to the joiner indicating which
point they have reached. This message MUST be
one of the standard statements described in
Section 3.
2.2 Acknowledgement
When the joiner receives a message from the
initiator they MUST send back the message [OK]
to indicate that they have received the message
and are taking appropriate action.
2.3 Resending
If the joiner sends a notification and does not
receive an acknowledgement within 20 seconds,
and has not already sent this notification three
times, they MUST retransmit the notification.
2.4 Exceptions
Failure to receive an acknowledgement after
three transmissions of a notification, or
receipt of any message that is invalid under SSP
indicates an abort. After an abort the
communicator SHOULD interpret the triggering
message and future messages, if any, using
whatever protocol they would otherwise use for
the underlying transport.
3 Notifications
3.1 Carriage Designation
When boarding the train the initiator MUST
choose either the initial or final carriage.
Other carriages offer a risk of confusion that
we consider excessive. An initiator who has
boarded the initial carriage SHALL transmit
[First car], while one boarding the final
carriage SHALL transmit [Last car].
Note that this notification also serves to
indicate departure from the initial station.
J. Kaufman Standards Track [Page 4]
---------------------------------------------------
RFC Subway Synchronization Protocol June 2015
3.2 Station Arrival
Upon arriving at a station, the initiator MAY
transmit the name of the station. If the
station immediately preceeds the agreed-on
merger station they MUST send such notification.
Sending notifications for the last two stations
is RECOMMENDED.
The station name MAY be abbreviated to a single
letter in cases where this is not ambiguous.
For example, upon arriving at Harvard station an
initiator could send either [Harvard] or [H].
4 Handling Notifications
On receieving each notification the joiner
knows the position of the train and SHOULD
estimate:
- the time required for their party to travel
to the agreed-on station
- the time the train will take to travel from
the next station at which notification is
mandatory to the agreed-on station.
If the second time is less than the first, the
joiner SHOULD begin travel to the station.
4 Merging
After the joiner and their party arrive at the
agreed on station they SHOULD wait opposite
either the initial or final carriage, as
communicated in the carriage designation
notification. When each train arrives they
SHOULD visually examine it for the initiator
party, and board if and only if visual
identification is successful.
If the initiator arrives at the station and
does not see the joiner, they SHOULD exit their
carriage and wait opposite it until the joiner
arrives.
When the two parties have converged they merge
to become a single party, the communicators lose
their designated roles, and any future messages
on the underlying transport SHOULD NOT be
interpreted under SSP.
J. Kaufman Standards Track [Page 5]
Comment via: google plus, facebook