Browse Prior Art Database

A METHOD OF FORWARD DOCUMENT SYNCHRONIZATION FOR N TO N POINT CONFERENCING WITH UNDO

IP.com Disclosure Number: IPCOM000007994D
Original Publication Date: 1997-Mar-01
Included in the Prior Art Database: 2002-May-10
Document File: 4 page(s) / 248K

Publishing Venue

Motorola

Related People

A. Hirsbrunner: AUTHOR [+3]

Abstract

To synchronize complex matrix conferencing (n entities in different locations making simultaneous changes to local copies of the same document where n>2) with differring transit delays between locations, the following method is used. We assume guaranteed (single target or broadcast) packet deliv- ery, and that packets will be received in order.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 25% of the total text.

Page 1 of 4

MOTOROLA Technical Developments

@

A METHOD OF FORWARD DOCUMENT SYNCHRONIZATION

FOR N TO N POINT CONFERENCING WITH UNDO

by A. Hirsbrunner, T. Gavin and S. Adler

INTRODUCTION DETAILED EXAMPLE

  To synchronize complex matrix conferencing (n entities in different locations making simultaneous changes to local copies of the same document where n>2) with differring transit delays between locations, the following method is used. We assume guaranteed (single target or broadcast) packet deliv- ery, and that packets will be received in order.

For the example:

  A ,B & C will numerically count the packets they send out (except for data packets)and fill in the packet number field.

  All packets will be numbered incrementally on the machines the packets are created on. This packet number will be unique to the packet (,and toany data packets associated with this packet). In the MagicPipe TM implementation the packet number will be appended to all packets as a Long field.

  A ,B & C will also remember the number of the last packet they received from each peer and fill that number in the last seen field list, i.e. if A is sending his packet #21 and the last packet received from B was #13 and the last packet received from C was #16, A would put pak#=21, lastPakB#=13, lastPakC#=16.

  A ,B & C will also have a buffer of all packets that they have sent out, and in the case above when B gets the 21st packet from A it knows that A has processed all of B's packets through 13 so it can clear out its packet store through packet 13. Similarly, when C gets the 21st packet from A it knows that A has processed all of C's packets through 16 so it can clear out its packet store through packet 16.

  Also, a set of n last packet seen numbers will be maintained (being the last packet received from each of the peers it is conferencing with) and will be appended to each packet sent out.

  The last step needed is for the machine to main- tain a buffer of packets sent out, and each time a packet is received from its peers, the lastpacket field can be checked, and all packets sent before that last packet (packets we now know to have been seen and executed by the peers) can be removed from the buffer.

  These four steps allow each machine to know the condition of the other machine when it created the packet, and have enough information to resolve a conflict without more communication..

  In order to resolve conflicts, we need some set of rules for what to do for each packet. In the next example we will assume that we have a MagicPipeTM conferencing session and A has initi- ated an active session to B and then C. We will use the existing MagicPipeTM conflict resolution scheme of letting the active session have prece- dence over the first and then second passive ses- sions (for commands like three creates and deciding which goes first.) The example is as follows:

From To pak

A W 1 C Bsl 1 B W 1

AlPak

0

0

BlPak 0

0

ClPak 0

0

packet creates an oval sid=lOl creates a poly sid=301 creates a re...