Distributing the data model

The choice of a line as the ADU was made in part due to the simple observation that most consecutive changes are made to a single line - generally because a user continues to type. Thus if the whole line is sent for every character typed the additional overhead (over just sending the changes) is not great, the data transfer is idempotent (assuming a version of the block has already been received), and a great deal of ``natural'' redundancy is available - so long as a user continues typing on the same line, lost packets are unimportant. However this is only the case if we take a loose consistency approach - changes are displayed as soon as the arrive, irrespective of whether other sites have received them.

In order to be able to use this ``natural redundancy'' property, it must be possible to identify whether a version of a line that just arrived is more recent than the copy of it we have already. This is necessary for two reasons - firstly to cope with misordered packets from a single source, and secondly to cope with retransmitted information from hosts with out of date versions of the data.

Misordered packets could be easily spotted using a sequence number; however out of date retransmitted data is not possible to identify in this way. If we assume synchronised clocks at all sites, recognising out of date information is very easy to achieve by simply timestamping every line with the tome of its last modification, and sending these timestamps along with the data. Packets containing a line or block with an out of date timestamp can be ignored at a receiver with a later version of the same data. If we wish to take advantage of redundancy by not requiring retransmission of many lost packets, and we have modification timestamps in the packets, then we have no use for a sequence number in the packets. In general a receiver does not care if it receives all the changes to a line as they happen; rather it only cares that it receives the final version of a line, and that it receives sufficient changes that users understand what it happening as it happens.

In practice, we can't assume synchronised clocks, but we can implement our own clock synchronisation protocol in the application. Also if a receiver sees a retransmission of out of date data, it should attempt to update the sender of that data - we shall discuss how this can be achieved scalably under retransmission schemes below.