MTP provides reliable multicast delivery on an one to many and many to many
basis. It may be used as the Transport layer of any network architecture
provided the datalink layer includes some support for multicast. Clients of MTP
need not be concerned with the geographical location and population of the web
members. It uses only a small number of control packets with the bulk of
syncronisation and control information being piggy backed onto client data packets.
Basic MTP parameters.
Heartbeat Window Retention
These parameters may be changed while a web is in operation to reflect the
network quality and the desired level of service.
Packet Format.
A transport packet consists of a fixed format transport header and a variable
length data component.
There are 7 packet types, data, nak, empty, join, quit, token, isMember, each of which has several different type modifiers.
All transmitted packets contain information about the status of the last twelve
messages, in the message acceptance vector. The status of a message may be
pending, accepted or rejected. Only the master may set
the status of a message. Messages are marked as accepted when the master has
seen the whole message, pending when the master has not seen the whole message
but suspects the producer is still active and rejected when the master suspects
the producer has died or been partition away. As all packets carry this information all members of the web can see the state of messages and can disregard
messages they received but where rejected by the master, or report failure if
they have been unable to get a message that was accepted by the master.
The process that is first to establish at a particular NSAP will be the
master of the web. It must make a robust effort to ensure that the NSAP is
not already in service, by sending repeated join requests. If it receives
no response it may assume the NSAP is not in use and may proceed with the
creation of the web.
NSAP's are used to provide three logical ports called TSAP's. These are formed
by concatenating the NSAP with a transport identifier. The TSAP's are unknown,
individual, and multicast. The unknown TSAP is only used be clients requesting
to join the web.
After the master has established a web at a particular NSAP other clients
may join the web be sending a join[request] to the unknown TSAP. The master
may respond to this message with a join[accept] or join[deny] message. A
join[accept] message includes the TSAP multicast address and
the masters TSAP. A join accept should only be issued when no producers are
in position of transmit tokens, so that the joining member will not observe
partial messages and may receive application state information.
When a producer wishes to send a message it applies to the Master with a
token[request] packet, this packet should be resent every heartbeat until the
Master responds with a token[confirm] packet. The token[confirm] packet
contains a message sequence number for the message the producer wishes to
send. The data part of the packet contains a list of multicast TSAPs which
are represented in the web. The producer may then send the data packets
which constitute the message, attaching to each the message sequence number
and an incremental packet sequence
number. The network setup of heartbeat, window and retention govern how the
message is sent. The producer must send at least one packet per heartbeat
(measured in milliseconds) and up to a maximum of window packets. If the Producer
has insufficient data to transmit a full data packet in a given heartbeat, it may
transmit an empty[dally] message. The value of
retention governs how long (in heartbeats) dispatched packets should be
retained by the producer so that they may be resent if requested by
consumers.
Requests for tokens are directed to the master's individual TSAP. The master
employs some fairness algorithm in responding to these requests with a
token[confirm] packet. As a minimum it should use a FIFO ordering system.
Note that the protocol allows for multiple transmit tokens.
After issuing a token[confirm] packet and not seeing any data or
empty[dally] packets from the intended recipient it must assume the token
lost. It can query the status of the recipient with an isMember[request] to
see if the recipient has died or become partitioned away from the web. In any
case the token is reclaimed by the master.
In responding with a token[confirm] packet the master must increment the current
message sequence number and shift the acceptance vector, so that the status
of the oldest message is shifted out and a new pending status is shifted in
to represent the new message. The status of pending may not be shifted out
of the acceptance message, so the master may not confirm any token[request]s
while a pending status is representing the oldest message.
If a consumer sees an out of sequence Message Sequence Number, Packet
Sequence Number pair, it applies to the producer to have the missing
packet(s) resent, by issuing a nak[request] message containing a list of the
missing packets. The producer will then resend (multicast) all the missing
packets, resending these packets will reduce the number of new packets the
producer may send in that window. Consumers must be able to cope with duplicate
packets. If some of the packets have been discarded (because they were sent
more than retention heartbeats ago) then the producer must respond with a
nak[deny] message, if the consumer receives a nak[deny] it must report this
loss to its client which may enter a failed state and have to withdraw from
the web.
MTP on Internet Protocol uses the Internet Protocol multicast
mechanisms defined in RFC 1112, "Host Extensions for IP
Multicasting". MTP requires "Level 2" conformance described in that
paper, for hosts which need to both send and receive multicast
packets, both on the local net and on an internet. IP multicast does not
provide the a port mechanism so a simple bridge protocol is needed to use
encapsulate MTP packets within IP packets.
Overview.
A period of time measured in milliseconds. It may be adjusted to suite network
conditions and desired quality of service.
The number of packets a producer may multicast into the web during a single
heartbeat.
The number of heartbeats a producer must retain transmitted packets in case they
need to be resent.
Establishing a web.
Joining a web.
Sending Messages.
Web Master
Data Loss.
MTP over IPmulticast.