| The Synchronization Protocol allows the transfer of large numbers of modifications or large payload objects when there are device limitations relating to the size of SyncML Messages. To achieve this, each SyncML Package can be divided into multiple SyncML Messages. This allows the synchronization of a large number of modifications or large payload data without exceeding the maximum size of a SyncML Message. Large Object Delivery The SyncML 1.0.1 specification does not include the functionality to divide a large payload object, such as an image file, into multiple Messages. That is, if a large data object within a SyncML command is transferred by utilizing the SyncML 1.0.1 specification, the command, including the data object, needs to fit into one SyncML Message. When considering the fact that the sizes of SyncML Messages range between a few kilobytes and tens of kilobytes, the overall size of the large object cannot be very large. The version 1.1 (and later) SyncML specification takes the delivery of large objects into account and provides the functionality for transferring data objects with sizes larger than the maximum size of a SyncML Message. From the Synchronization Protocol point of view, the functionality for transferring large objects over multiple Messages means that a segmentation and reassembly feature is provided inside SyncML commands such as Add and Replace. This is like any segmentation and reassembly feature provided by other transport protocols, but now it can be used inside individual SyncML commands. For example, if a Server wants to add a large picture to the image database of a Client, but the size of the image is larger than the Message size that can be received by the Client, the Server will distribute the image over multiple SyncML Messages. Maximum Size of SyncML Messages Before analyzing the features for transferring large numbers of modifications or large payload objects, it is worth considering the factors that affect the maximum size of a SyncML Message. The Client and the Server can define how large a SyncML Message they can receive and send. Any or all of the following reasons may ignore the size of a SyncML Message: Internal characteristics of a device Transport protocol for encapsulating SyncML Messages Properties of a gateway to access a network Underlying physical networks
The first reason in the list is quite obvious when considering that SyncML devices can vary from small wireless embedded devices to large enterprise servers. Commonly, an internal characteristic affecting the maximum size is the amount of RAM (Random Access Memory) available for buffering a SyncML Message. In a small wireless device, the RAM available for buffering is usually on the order of a few tens of kilobytes, and rarely more. There are other characteristics as well, but RAM limits may be the most compelling one in wireless devices. The transport protocol carrying SyncML Messages can also have an impact on the maximum size of a Message. This is the case if the transport protocol does not offer the functionality for chunking data over a network. This means that a SyncML Message can be transferred in small pieces and reassembled at the destination. Not all protocols offer this kind of functionality; some are only able to transfer complete SyncML Messages. One example of this kind of protocol is the Wireless Session Protocol (WSP) [WSP01] defined by the WAP Forum®. The third factor affecting the maximum size can be the gateway used for accessing a network. A WAP gateway (interconnecting a wireless network and a fixed network) is a good example of a gateway that limits the maximum size. When a wireless device connects over WAP to the Internet, the limitations of the WAP gateway can be more restrictive than the internal characteristics of the device. The maximum size in such a situation is determined by the characteristics of the WAP gateway, not the internal limitations of the wireless device. The underlying physical network can have design-oriented issues impacting the maximum size of a Message. In other words, larger-size Messages can affect the robustness and performance of the system. When implementing SyncML on devices enabling connections over fixed networks or wireless networks, the fundamental characteristics of these networks, such as data rate and latency, must be taken into account. Multiple Messages per Package A Client or a Server will need to divide a large amount of modifications into multiple Messages if they do not fit into one Message. For example, a Server has fifty modifications to be sent to a Client. However, the maximum size of a SyncML Message that can be received by the Client would be exceeded if the Server embedded all the modifications into one SyncML Message. Thus, the Server must distribute the modifications over multiple Messages. As defined in the Representation Protocol, specifying a Final tag inside a Message indicates the end of a SyncML Package. If the tag is not specified, a Package is not completed yet and more Messages for the same Package need to be received. The Synchronization Protocol is designed so that if a device receives a Message without a Final tag, it needs to ask for a next Message, explicitly or implicitly. An explicit request means that the device that received the incomplete Package sends a special alert. An implicit request is done by sending the status information related to the Message or to commands within the Message. It is possible to use both ways simultaneously. The implicit way alone may be more common and recommended, as devices in general require the status information to be sent. Thus, the implicit request often comes automatically, in which case the explicit request would only be redundant. Naturally, if a device does not request any response to a Message without a Final tag, the explicit request mechanism needs to be used. Figure 5-6 shows an example of using multiple Messages. In this example, Package #3 is distributed over multiple Messages. In the figure, it is shown that Package #4 is divided into two Messages, as all the modifications from the Server to the Client cannot be included in the first Message belonging to Package #4. The example uses both the implicit and explicit ways for requesting more Messages. Figure 5-6. Example of using multiple Messages per Package 
| 
