System and method for synchronization of server and customer

System and method for improved synchronization between server and client

References to Related Applications This application claims priority for the following applications: U.S. Application No. 60/437869, Attorney's Note No. 220635, filed on January 3, 2003, entitled "Improved System and Method for Client-Server Communication" (SYSTEM AND METHOD FOR IMPROVED CLIENT SERVER COMMUNICATIONS), this application is incorporated herein by reference.

(1) Technical Field The present invention generally relates to computer networks, and more particularly to methods for communication between a client and a server, such as an email application.

(2) Background Art Mail has become an important method of communication. The mail system generally includes a server component (for example, Microsoft Exchange Server, Microsoft Exchange server) and a client component (for example, Microsoft Outlook or Microsoft Outlook Express). These components are generally software applications that execute on computing devices (eg, servers, PCs, laptops, and PDAs).

Generally, in order to facilitate communication, the client and server, such as the client component and server component of a mail system, agree on a communication protocol. The protocol proposes rules that define the expected behavior of the parties during the communication, for example, the expected sequence of requests and responses. Complex agreements have rules for handling unexpected behavior.

As the client and server were improved, the improved version was distributed to end users. In order to take advantage of new component features and network features, new communication protocols are usually invented. When the installed base of the server component is significant, the client component may be able to communicate with the selected previous version of the server component through a set of protocols.

Sometimes later agreements build on earlier agreements rather than replace them on a large scale. In this case, the latter protocol can be composed of protocol elements, which can be enabled or only have protocol elements to simulate earlier protocols. Similarly, when the installed base of the client component is significant, the server component can also communicate with the selected previous version of the client component through a protocol.

The present invention provides such a system and method. From the following description of the present invention, these and other advantages of the present invention, as well as additional inventive features, will become more apparent.

(3) Summary of the invention The present invention provides systems and methods for improved client and server communication. More specifically, the present invention is directed to improved protocols that may be used for communication between a client and a server. The present invention is particularly relevant to mail server environments, but the features described here can also be used in other client and server networks.

According to an aspect of the present invention, even if a mail change occurs at another mail server component, the mail change at this mail server component can be optimized. The first mail server component discontinues first data related to changes in mail information seen by the mail client component. The second mail server component maintains second data related to changes in mail information seen by the mail client component. The second mail server component then optimizes the intermittent first data.

According to another aspect of the present invention, the mail server component may maintain a list of changes that occur at the relevant data storage, and may notify the subscribed mail client component of the changes that occur in the list. Maintain a list of changes made to multiple folders containing mail data objects. The mail client component subscribes to the table and sends notifications to the mail client component according to changes in the table.

According to another aspect of the present invention, the mail server component may cancel the notification to the mail client component that has caused a change to the form. The mail server component may receive an instruction, requesting that the first mail client component not be notified according to the change, and according to the change and instruction, the notification related to the change is sent to all subscribers of the form, instead of the first mail client Machine components.

(4) Description of the drawings Figure 1 is a schematic diagram of a computer connected to the network.

Figure 2 is a schematic diagram illustrating an exemplary computer system that can be used to implement embodiments of the present invention.

Figure 3 is a schematic diagram depicting an environment with multiple versions of both the mail client component and the mail server component.

Fig. 4 is a protocol diagram showing an example of a protocol negotiation process between a mail client component and a mail server component.

Fig. 5 is a schematic diagram showing an example mail network in which the mail client component and the mail server component have fixed-size communication buffers.

FIG. 6A is a protocol diagram showing an example protocol that requires two request-response cycles to complete a fast transfer operation.

FIG. 6B is a protocol diagram showing an example protocol that requires a single request-response cycle to complete a fast transfer operation.

FIG. 7A is a flowchart describing an example process of sending the body of the mail message to the mail client component.

FIG. 7B is a flowchart describing the process of sending the body of the mail message to the mail client component according to an aspect of the present invention.

Fig. 8A is a sequence diagram illustrating the complete entry transmission mode.

Fig. 8B is a sequence diagram illustrating the header priority transfer mode.

Fig. 8C is a sequence diagram illustrating the header-only transmission mode.

Fig. 8D is a transmission mode sequence diagram illustrating a special case of header priority and header only.

Fig. 9 is a schematic diagram showing a home mail server component of a mail client component that changes over time.

Fig. 10 is a protocol diagram showing an example protocol for synchronizing mail folders between a mail client component and a mail server component.

Figure 11A is a flowchart describing an example process for optimizing a partial state block (stateblob).

FIG. 11B is a flowchart describing a process for optimizing a part of the state block according to an embodiment of the present invention.

Fig. 12 is a schematic diagram illustrating the hierarchy of mail folders.

FIG. 13 is a protocol diagram showing an example protocol for synchronization and synchronization maintenance of mail information storage according to an aspect of the present invention.

Figure 14A is a protocol diagram showing an example protocol for transmitting error information at the ROP level.

FIG. 14B is a protocol diagram showing an example protocol for transmitting error information on a per-message basis according to an aspect of the present invention.

Figure 15A is a flowchart describing the process of generating error messages at the ROP level.

Fig. 15B is a flow chart describing the process of generating error messages on a per-message basis according to one aspect of the present invention.

FIG. 16A is a protocol diagram showing an example protocol for realizing a fast transfer operation.

FIG. 16B is a protocol diagram showing an example protocol for providing progress information while realizing a fast transfer operation according to an aspect of the present invention.

Figure 17A is a flow chart describing the process for streaming a set of information.

FIG. 17B is a flowchart describing a process for streaming a set of information along with progress information according to an aspect of the present invention.

Figure 18 is a schematic diagram of multiple mail client components being notified due to changes to the same data object at the mail server component.

Figure 19A is a flowchart describing a process for notifying multiple subscribers.

Figure 19B is a flowchart describing a process for notifying multiple subscribers according to an aspect of the present invention.

FIG. 20 is a flowchart describing a process for providing mail information using a desired code page according to an aspect of the present invention.

(5) Specific implementation mode Before continuing to describe the various embodiments of the present invention, a description of the computer and network environment in which the various embodiments of the present invention can be practiced will now be provided. Although not required, the present invention can be implemented by a program executed by a computer. Generally speaking, the program includes routines, objects, components, data structures, etc. that can perform specific tasks or implement specific abstract data types. The term "program" as used herein means a single program module or multiple program modules acting together. The term "computer" as used herein includes any device that electronically executes one or more programs, such as personal computers (PCs), portable devices, multi-processor systems, microprocessor-based programmable user electronic devices, network PCs, Microcomputers, tablet PCs, mainframe computers, user equipment with microprocessors or microcontrollers, routers, gateways, hubs, etc. The present invention can also be used in a distributed computing environment, where tasks are performed by remote processing equipment connected through a communication network. In a distributed computing environment, programs can be located in local storage devices or remote storage devices.

An example of a network environment in which the present invention can be used will now be described with reference to FIG. 1. An example network includes several computers 10 communicating with each other on a network 11 represented by the cloud. The network 11 may include many well-known components, such as routers, gateways, hubs, etc., and allow the computer 10 to communicate through wired and/or wireless media. When interacting with each other on the network 11, one or more computers may act as clients, servers, or peers with other computers. Thus, various embodiments of the present invention can be practiced on a client, a server, or a combination thereof, even if the specific examples contained herein do not refer to all these types of computers.

Referring to Fig. 2, it shows an example of a basic configuration of a computer on which all or part of the present invention can be implemented. In the most basic configuration, the computer 10 generally includes at least one processing unit 14 and a memory 16. The processing unit 14 executes instructions according to various embodiments of the present invention to achieve tasks. When implementing these tasks, the processing unit 14 may send electrical signals to other parts of the computer 10 and send them to devices external to the computer 10 to cause certain results. According to the actual configuration and type of the computer 10, the memory 16 may be volatile (such as RAM), non-volatile (such as ROM or flash memory), or some combination of the two. Figure 2 illustrates the most basic configuration with a dashed line. In addition, the computer may have additional features/functions. For example, the computer 10 may further include additional storage (removable storage 201 and/or non-removable storage 202), including, but not limited to, magnetic or optical disks or tapes. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented by any method or technology for storing information. Information includes computer-executable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to: RAM, ROM, EEPROM, flash memory, CD-ROM, digital video disc (DVD) or other optical storage, magnetic tape, magnetic tape, magnetic disk storage, or other magnetic storage devices, or can be used for storage Ideal information and any other medium that can be accessed by the computer 10. Any such computer storage medium can be part of the computer 10.

The computer 10 preferably also includes a communication connection 205 that allows the device to communicate with other devices. A communication connection is an example of a communication medium. The communication medium generally contains computer readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave or other transmission mechanism, and includes any information transmission medium. For example, but not limited to, the term "communication media" includes wired media such as wired networks or in-line connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media. The term "computer-readable medium" as used herein includes both computer storage media and communication media.

The computer 10 may also include devices 204 such as a keyboard, a mouse, a stylus, a voice input device, a touch input device, and so on. It may also include an output device 203, such as a display 20, a speaker, a printer, and so on. All these devices are well known in the art and need not be discussed here.

The present invention is directed to systems and methods for improved client and server communication, and in particular to improved protocols that can be used for communication between client and server. The present invention is particularly concerned with mail server environments, but the features described here can also be used in other client and server networks. However, for simplicity of description, the present invention is described with reference to the client/server mail environment.

The present invention can be implemented in a client/server environment that has two or more versions of client applications or components, and/or two or more versions of server applications or components. To this end, Figure 3 illustrates a block diagram showing multiple versions of client and server components in a webmail environment. Generally, configure the client and server components to make them backward compatible. That is, the client component can communicate with the latest and traditional version of the server component, and vice versa. A set of protocols is established to communicate between multiple versions. This set of protocols can be composed of several different protocols, each of which is self-contained. Or, a set of protocol components are available, and a specific component is used to configure a specific protocol in the protocol group.

In any case, in the network mail environment shown in FIG. 3, the latest version of the mail client component 303 can optimally communicate with the latest version of the mail server component 306 using the protocol 307. However, the latest mail server component 306 can also use other protocols in the protocol suite (eg, protocols 308 and 309 in FIG. 3) to communicate with the selected mail client component of the previous version, for example, the mail client component 302 And the mail client component 301. The mail client component 303 can also use protocols such as protocols 310 and 311 to communicate with selected mail server components of previous versions, for example, the mail server component 305 and the mail server component 304.

Generally speaking, as used here, in order to describe the protocol of the present invention, the "latest" mail (server or client) component, that is, the latest version of the mail (server or client) component, is aware of new features and The server or client component of the described features, and can use, implement, and/or act on those features. Although these terms are used throughout this document to describe client and server components that are aware of various aspects of the protocol of the present invention, these terms also include components that only know the specific aspect or more than the one aspect. Similarly, the "previous" mail component (that is, the mail component of the previous version) is a component that is unknown and cannot be used for all aspects of the protocol of the present invention.

The protocol negotiation process is usually used to establish an agreement between the client and the server (eg, the latest version of the mail server component 306 and the latest version of the mail client component 303). Although this protocol negotiation is known, a brief description of the protocol negotiation process between the mail client component 401 (FIG. 4) and the mail server component 402 is provided for readers. Initially in the communication session between the mail client component 401 and the mail server component 402, the mail client component 401 sends a message 403 including the client version information to the mail server component 402, for example, with the client component version stamp (stamp) form. The mail server component 402 responds to the message 403 with a message 404 including client version information, for example, the message 404 is in the form of a server component version mark.

To attempt to establish communication between the mail client component 401 and the mail server component 402, the client and server version information can be used in a variety of ways. For example, the version information can be used to select an appropriate protocol for continued communication, or to determine whether further communication is feasible. For example, when establishing a protocol, the version information can be used to enable and/or disable specific available protocol aspects or components.

The mail server component may receive and process requests from multiple mail client components in parallel. Where a single client is shown, unless otherwise specified, this is only for simplifying the drawings and accompanying descriptions.

The mail network of the present invention uses request and response exchanges to transfer queries and data between client and server components within the network. In practice, the performance of the protocol may be affected by the underlying communication network transmission mechanism, which is used to implement the communication between the client and the server within the mail network. For example, in a mail network that uses remote procedure call (RPC) as the basic communication network delivery mechanism, a single remote procedure call using a larger size (eg, 32KB) may be far more than using several smaller sizes (eg, 2KB). The remote procedure call is more efficient. One known way to improve performance in this type of mail network is to buffer multiple requests and/or responses for transmission within a single remote procedure call.

For example, FIG. 5 shows the exchange of requests and responses between the mail client component 501 and the mail server component 502. The mail client component 501 and the mail server component 502 each have fixed-size communication buffers 503, 504, 505, and 506. The buffers 503, 504, 505, and 506 are storage reserved areas for temporarily holding data. The mail client component 501 starts the request-response cycle by filling the buffer 503 with one or more sub-requests or remote operations (ROP) before sending the contents of the buffer 503 to the buffer 504.

After the ROP is received by the buffer 504, each ROP is processed so that the corresponding result is written into the buffer 505 through the mail server component 502. Each ROP does produce some results. The result may include data requested by the mail client component 501, for example, a specific set of mail information. The mail server component 502 monitors the buffer 505. When it is almost full (for example, the remaining part is less than 8KB), the mail server component 502 writes any unprocessed ROPs to the end of the buffer 505 and sends the buffer 505 to the bufferArea506. Then, when the buffer 503 becomes full again, the mail client component 501 writes the unprocessed ROP into the buffer 503 for submitting to the mail server component 502 again, thereby starting a new request-response cycle.

The size of the response is generally larger than the size of the request on average. For this reason, the size of the response buffers 505 and 506 is generally configured to be larger than the size of the request buffers 503 and 504. In an embodiment of the present invention, for the request buffers 503 and 504 with a size of 32KB, the optimal size of the response buffers 505 and 506 is determined to be 96KB, with a ratio of 1:3. In one embodiment, the mail client component can be configured with any size of buffers 503, 504, 505, and 506.

Some mail networks that use buffers, such as the mail network shown in Figure 5, can adopt a fast transfer mode between the mail client component and the mail server component. The fast transfer mode includes client requests, such as ROP, which are divided into at least two types: requests that result in the initialization of a fast transfer data source at the server, and requests that cause efficient transfer of data from the fast transfer data source to the client. For example, the fast transfer data source can be a database table. The fast delivery data source serves as a ready temporary storage of data, and it can serve later requests for data with lower latency. Sometimes, the second fast transfer mode requests to try to achieve effective data transfer by explicitly specifying the response size. For example, the response size can be set to the size of the entire client receiving buffer minus the response overhead.

Figure 6A shows a fast transfer operation with at least two request-response cycles. In the first request 601, the ROP (eg, FXPrepare) initializes the fast delivery data source on the server 502. At the server, only FXPrepare is processed (ie, the fast delivery data source is initialized), and the result is returned in the first response 602. In the second request 603, the ROP (eg, FXGetBuffer) requests the server to fill the buffer 505 from the fast data source. The server empties the fast data source to the buffer, and returns the result in the second response 604. If the output buffer 505 of the mail server component fills up before the fast data source is drained, an additional FXGetBuffer ROP may be required.

FIG. 6B shows a fast transfer operation with only a single request-response period. In the first request 605, the mail server component 502 processes both FXPrepare and FXGetBuffer, and the results of both operations are returned in the first response 606. Since a part of each buffer 503, 504, 505, and 506 is explicitly defined as a shared data table, the result of FXPrepare can be used in the FXGetBuffer at the mail server component 502. It is desirable to reduce the number of request-response cycles, as this will result in more efficient data transfer. When the buffer 505 is too full to hold the result of the FXGetBuffer ROP, a fast transfer operation with more than a single request-response cycle may occur.

It can be understood that the ROPs in FIGS. 6A and 6B and similar drawings in this application are schematic, because they can be implemented by a series of ROPs in practice, unless otherwise specified.

Generally speaking, the size of the ROP result is different from the size of the ROP request. It is not always possible to predict the size of the ROP result. When data compression techniques are used to reduce the size of the ROP result, it is more difficult to predict the size of the ROP result. The inability to predict the size of the ROP result prevents manual tuning of the protocol and minimizes the number of request-response cycles required to complete a specific client operation, for example, to ensure that all new information is downloaded to the client within a single request-response cycle . The manual tuning protocol includes manually configuring the sequence and/or size of protocol requests, responses, and/or ROPs.

According to one aspect of the present invention, the size of their results is predicted by indicating that no key ROP (such as FXGetBuffer) is needed, thereby automatically minimizing the number of request-response cycles. However, this type of ROP is processed by the mail server component 502 until the limit of the buffer 505 (the same as the buffer 506) is reached.

For example, in an environment that includes multiple versions of mail server components, separate ROPs can be defined for the server components of the previous version and the server components of the latest version. The latest version is not needed to predict the size of their results. The characteristics of these ROPs are listed in the following table:

The ROP of the server components of the previous version is similar in structure to the prior art ROP. That is, the ROP predicts and specifies that the size of the output buffer (for example, the send buffer 505) must be reserved for holding the response. In contrast, the size specified by the output buffer of the latest version of the server is not predicted, but is set to be above the maximum value expected by the server components of the previous version, for example, set to a value greater than 32KB. Defining the size of the output buffer to be higher than the value expected by the server component will cause the server component to find a new size limit parameter, which can be, for example, the filling of the output buffer of the server component. These features automatically minimize the number of request-response cycles and only slightly increase the complexity of the mail server component that handles ROP.

Note that the order of parameters shown in the above table and similar tables in this application is not necessarily related to the order in which the parameters are sent on the network or the order in which they are stored in the memory by the mail client component or the mail server component, unless otherwise specified. In addition, the unchanged parameters can be omitted for brevity.

In the mail network, one of the general purposes of the protocol is to realize the transmission of data objects, for example, mail information between the mail client component and the mail server component. Further examples of such data objects include mail folders that may contain mail information and other data objects, and folder-related information (FAI) data objects. For example, the latter may contain rules for processing mail information, or define what will happen Display the data objects contained in the folder. The data object may be opaque to the mail client component; that is, the mail client component may not be able to interpret the contents of the data object. Or, the data object may consist of named attributes. For example, the mail message may include names named "to", "from", "subject", and "importance". ", "body1", "body2", "body3", "attachment1", "attachment2" and so on.

One advantage of the mail network is that it can potentially improve the performance of the protocol. This is because the protocol can only transmit part of the data object. In the mail network, the data object may include the named attributes on the mail network where the data object is opaque. Having named attributes allows specific attributes of the data object to be sent without sending the entire data object.

For example, mail information may include a set of header attributes and a set of body attributes. The requirement of the mail client component may be that the protocol transmits the header attributes first, but transmits the body attributes or not at all. This feature allows users to view the header information of several messages before downloading all the messages completely. By using this feature, client components can obtain finer control over bandwidth utilization, which will positively affect protocol performance. In addition, the client can use this feature to cause lower bandwidth utilization (for example, it may only download the text for the selected header), which is especially ideal in a low-bandwidth environment.

If the server component is configured to send the body and header attributes in two separate request-response cycles (ie, the header and the body each use one cycle), it is not necessary to increase the performance of the protocol. For example, if the requirement of the mail client component is to require header and body attributes at the same time, the protocol performance may be degraded if the header and body can be retrieved in a single request-response cycle. Therefore, simply including named attributes in the data object is not enough to automatically lead to improved protocol performance. Achieving improved protocol performance depends on the choice of attributes that make up the data objects and how they are used by the protocol. The choice may depend on many factors, including the requirements for the latest and previous versions of the mail client components, and the requirements for the latest and previous versions of the mail server components. Examples of mail client component requirements include meeting different urgency levels for displaying different information, and conforming to preferences set by users of the mail client component. Examples of mail server component requirements include effective storage and retrieval of data, and effective processing of protocol requests.

The conventional prior art mail environment uses data objects that can be composed of named attributes, for example, mail information that may include a header group and a body group of the named attributes, so that these two groups can be requested and/or processed separately. Another prior art example is an email message, where the body naming attribute group includes multiple versions of the email message body, for example, in multiple versions such as plain text, hypertext link markup language (HTML), rich text format (RTF), etc. Kind of mail message format. In this case, the prior art mail server component may respond to the protocol request of the mail message body in a variety of ways. The least complex response may be to send all versions of the message body, but this response may result in increased bandwidth usage.

Figure 7A describes a part of the process used by the previous (prior art) version of the mail server component to respond in this situation. In step 701, the mail server component checks the format of the body of each mail message. If one of these formats is a predetermined standard format (for example, RTF), the process moves to step 703, and the standard format mail message body is sent to the mail client component that is requesting. If no format is a predetermined standard format, step 701 branches to step 702, in which one of the mail message body versions is converted into a standard format. When there is only a single mail message body version, but the mail message body is not in the standard format required by the protocol, the sub-process described in FIG. 7A can also be used.

Figure 7B depicts part of the process used by the latest version of the mail server component according to the present invention. In step 704, it is checked whether the protocol request that caused the sub-process to be used by the mail server component has the BEST_BODY flag. The flag in this example and other flags used here are used for the mail server component, so that the mail client component is the latest version, and it is expected to implement the functions related to the flag. Other instructions can also be used. For example, if the latest mail client component is detected, this function can be implemented by default.

In any case, if the BEST_BODY flag is not found, step 704 branches to step 701, and continues as described with reference to FIG. 7A.

If the flag is found, the process moves to step 705, where the best mail message body is selected for sending to the mail client component that is requesting. It is best if only a single mail message body is related to the requested mail message. If there are several mail message bodies available, for example, in different formats, the mail server component selects the best one according to a predetermined arrangement such as the mail message body format (eg, RTF, HTML, plain text). Then, the process proceeds to step 703, in which the selected mail message body is sent to the mail client component. In this embodiment, the mail client component may be able to display a variety of mail message body formats, so that the mail server component does not need to convert the mail message body into a standard format. In addition, the mail client component can convert the best mail message body into different formats according to needs.

Since the task of the mail server component to transform the message body is alleviated, the present invention provides improved performance. In addition, the latest version of the mail server component may respond to protocol requests from the previous version of the mail client component, while only moderately increasing the complexity.

ROP may be used to implement mail folder replication between mail server components and mail client components. For example, SynchroFolder Rop may make a request to synchronize folders. Where the mail client component can display the non-standard mail message body format, it can set the BEST_BODY flag in the SynchroFolder ROP to designate the mail server component can choose the best format from the available mail message body instead of requiring the server to return the standard format The body of the email message. The mail server component can appropriately handle ROPs with or without the BEST_BODY flag, while only moderately increasing the complexity. The ROP used to communicate with the previous version and the latest version of the server may include, for example, the features presented in the following table:

Figures 8A-8C show several different existing modes for passing a set of mail messages between the mail server component and the mail client component. For each mode, each mail message has named attributes including header group and body group, and several mail messages are contained in a folder. Figure 8A illustrates the complete entry transfer mode. The description shows the first mail message header 801 being transmitted, then the first mail message body 802 before the second mail message header 803, then the second mail message body 804, and so on, until it has been transmitted This group of mail information so far. Figure 8B illustrates a header priority transfer mode. In this mode, the first mail message header 805 is transmitted first, then the second mail message header 806, and so on, until all the mail message headers are transmitted, and only then will the first mail message body 807 be transmitted. Then there is the second mail message body 808, and so on, until the group of mail messages is transmitted. Figure 8C illustrates the header-only transmission mode. As indicated in the name, in response to a request for sending a group of email messages, only the email message header 809 is sent. The mail message body 810 is only transmitted in response to an additional explicit request. In any of these modes, the delivery sequence may be temporarily interrupted by a higher priority mail client component request, for example, for a specific mail message body.

A mail folder is an example of a destination requesting the delivery of a set of mail information. However, mail folders may contain data objects other than mail information. As mentioned above, the transmission mode is usually defined by referring to the mail message header and the mail message body, such as header priority and header only transmission mode. In these modes, if the header group of the named attribute and/or the body group of the named attribute are not well defined for the data object, the attempt to transmit these data objects may cause the protocol to malfunction. On the one hand, the present invention avoids this situation by transmitting the data objects of the header and/or body group whose naming attributes are not well defined in general rather than partly. This embodiment can be illustrated by the example of FIG. 8D. In this example, the transfer between the mail server component and the mail client component may occur in a header-only mode. Thus, the first mail message header 811 is transmitted, and then the data object 812 becomes the next candidate for transmission. The header group of named attributes is not well defined for the data object 812, such as FAI, so the entire data object is transmitted. The next candidate delivery has a well-defined named attribute header group (that is, the candidate data object does handle all named attributes that are explicitly defined as belonging to the named attribute header group by the mail client component), so only mail information is delivered Head 813.

An exemplary way to implement this aspect of the present invention is by using a flag, such as IGNORE_MDE_ON_FAI, which can be included in a synchronous ROP, such as the aforementioned SynchroFolder ROP. The mail server component can appropriately handle ROPs with or without the IGNORE_MODE_ON_FAI flag, while only moderately increasing the complexity. ROP may include the features proposed in the following table to realize the replication of mail folders between mail server components and mail client components:

Mail messages are generally addressed to one or more mail network users. If the mail message is received by the mail server component for storage, it is deemed to have been delivered. The mail network may have several mail server components. Generally speaking, mail network protocols have certain policies that limit the number of mail server components so that mail network users must check for new information. A common example is a local server policy, which allows mail messages addressed to a specific mail network user to be accepted only by a specific mail server component, which is called the user's local server. In this case, the mail client component can be configured to consider only the local server when periodically checking for new mail information or registering for new arrival mail notifications.

Figure 9 shows that even a simple local server policy example can have its complexity. In the example shown in FIG. 9, the specific mail server component 901 is first designated as the local server of the specific mail network user. Over time, the local server designated for the user becomes different mail server components 903 and 905, generally for administrative reasons. For example, the mail server components 901, 903, and 905 may be physically different, or logically different, or in different versions. The mail client component 902 may only communicate with the mail server component 901 from time T0 to time T1, then the mail client component 904 may only communicate with the mail server component 903 before time T2, and then the mail client component 906 may only communicate with the mail server The component 905 communicates. The mail client components 902, 904, and 906 may be the same or different. The mail server components 901 and 903 may or may not exist after time T2. These complexities are especially related to the mail message storage replication discussed below.

The mail information can be stored by the mail server component in the explicit mail information storage, and the latter can be implemented using known database technology. The mail server component may have one or more such information stores. Mail network users may have a local information store. Changing the local information store will have the same effect as changing the local server.

Some mail network protocols can copy part of the mail information storage to the local storage device of the mail client component. Copying part of the remote mail information storage to the local mail storage device can improve the protocol performance and/or the observed protocol performance by copying all the new mail information to the local mail storage device before the explicit mail network user requests to observe the new mail. This kind of replication can also provide additional mail client component functions, for example, allowing mail network users to view mail information during a network interruption.

In the mail network environment, simple replication can quickly become inefficient. For example, if the mail server component has a mail message related to a specific mail network user, and the information has been copied at the client component of the network user, and new mail information arrives at the mail network user, then a simple copy of the response is still required Request and send two email messages. If another new mail message arrives after copying two mail messages, it is still required to send three mail messages in response to a simple copy request, and so on. In order to alleviate this problem, some mail network protocols have provided incremental replication of mail information storage. In incremental replication, in response to the replication request, only the changes in the mail information storage that occurred after the previous successful incremental replication are sent, for example, when the only change since the last successful incremental replication is the arrival of new mail information, the response Incremental copy requests only need to send the new mail message.

Figure 10 shows a more detailed example of a protocol that provides incremental replication. The mail information store can then be divided into mail folders. Each mail folder can be replicated independently of the others, providing more precise control over the replication process. In this example, since the incremental replication process includes propagating changes from the mail client component 501 to the mail server component 502 and from the mail server component 502 to the mail client component 501, the incremental replication process is called synchronization. After the synchronization request 1001, the mail server component 502 processes the SynchroFolder ROP. The ROP includes a folderID parameter (not shown) and a stateblob0 parameter. The FolderID parameter identifies the mail folder that is the target of the synchronization request 1001. The Stateblob0 parameter contains information that allows the mail server component 502 to determine the changes that have occurred to the mail folder since the last synchronization. If the request 1001 uses the mail client component 501 to represent the first synchronization request of the target folder, the mail server component 502 determines whether the target mail folder in the mail information store has changed compared with an empty folder. In response 1002 to the request 1001, the mail server component 502 sends out any changes to the mail client component 501, including any mail information and/or other data objects that have been added to the target folder, and have been deleted from the target folder Any mail information and/or other data object list of. The mail server component 502 also creates a new stateblob1, which represents the state of the target folder on the mail client component 501 immediately after synchronization, and sends the stateblob1 in the reply 1002. When the mail client component 501 makes a next synchronization request 1003 for the same folder as the request 1001, the request 1003 will include the same stateblob1 parameter as returned by the response 1002. As before, the mail server component 502 will use the information contained in stateblob1 to determine whether any changes have occurred in the target folder, and send those changes back to the mail client component 501 in response 1004 along with the newly created stateblob2.

If the size of the state block data object is large, it will adversely affect the performance of the protocol, because it is sent to or returned from the mail server component according to each mail folder synchronization request. In some mail network protocols that provide mail folder synchronization, a large part of the status block is composed of a set of information changeID (change identification) data objects, which represent the changes to the mail information seen by the mail client component. Mail information changes can be seen by the mail client and/or server component when the changed mail information is transmitted to the component.

One goal of the information changeID data object is to uniquely identify changes to mail information in the entire mail network environment. In the mail network adopting the local server strategy, the user's local server may be responsible for associating the information changeID data object with previously unseen mail information changes. For example, the local server may use an information changeID data object composed of a serverID (server identification) data object and a serial number. The ServerID data object can uniquely identify the mail server component in the entire mail network environment using well-known technologies such as a globally unique identifier. When the size of the identifier itself is large, the serverID data object can instead be an index in the identifier lookup table maintained by the mail server component. The serial number can be provided by a counter local to the mail server component, for example, a counter with a width of six bytes. The counter is incremented when the mail server component accepts previously unseen mail information for storage.

For discussion purposes, the information changeID data object can be represented by "S1:1", where "S1" represents the serverID data object of the first mail server component, and "1" represents the serial number. A group of information changeID data objects can be represented by "S1:1, S1:2, S1:3", where "S1:1", "S1:2" and "S1:3" are composed of mail server components with serverID S1 The continuous information used is the changeID data object.

When a large part of the status block is composed of a group of information changeID data objects, this group of data objects represents the mail information changes seen by the mail client component ("Message Changes Seen" group), then in order to reduce it Some techniques have been developed to encode the group based on size. For example, the group "S1:1, S1:2, S1:3, S1:4" can be coded as "S1:1-4". In addition, the mail server component can ensure that the serial number it uses is always increasing. In this case, discontinuous information changes like "S1:1, S1:3, S1:5, S1:7" can be coded as "S1:1-7", that is, coded as Include the range of minimum and maximum serial numbers without loss of functionality.

In the scenario shown in FIG. 9, the information change seen group may include an information changeID data object created by mail server components (e.g., S1, S2) other than the current local server (e.g., S3). The information changeID data object created by the current local server can be referred to as native information changeID, and the information changeID data object created by other mail server components can be referred to as foreign information changeID. The mail network protocol that communicates with the mail server components of the previous version does not optimize the discontinuous foreign information changeID sequence to include the minimum and maximum sequence numbers for each mail server component one by one. The following table illustrates the benefits of including this optimization in an embodiment of the invention:

An embodiment of the present invention uses a ROP including the characteristics listed in the following table to implement mail folder synchronization between the mail server component and the mail client component. The mail server component can implement an improved state block coding technique, while only moderately increasing the complexity.

Figures 11A and 11B describe the differences between the sub-processes used by the previous version server and the latest version server to respond to the SynchroFolder ROP, respectively. FIG. 11A shows steps 1101, 1102, and 1103. In step 1101, the group of initial information changes is constructed. In step 1102, the optimization information is a member of the local information changeID data object whose information changes have been seen. In step 1103, the optimized information change has been added to the state block data object, and the latter is sent to the mail client component requesting synchronization along with the reply. Figure 11B includes an additional step 1104, which shows the members of the foreign information changeID data object's information change has been seen group, they are also optimized before the information change has been added to the state block data object in step 1103, now With improved optimization.

Although subdividing the mail information storage into mail folders does provide more precise control over the synchronization process, it does not automatically improve the protocol performance and may result in degradation of the protocol performance. For example, some protocols require that each information storage folder be synchronized separately. Each synchronization operation generally has some overhead, which can be huge. Synchronous operations using state block data objects are examples of operations that have significant overhead. In the case of synchronizing the entire information store, a protocol that requires separate synchronization of each information storage folder may be disadvantageous compared to a protocol that requires less synchronization operations.

Synchronizing the entire information store and maintaining synchronization is the desired goal of the mail client component. The conventional prior art mail client component manages to achieve this goal even when it causes a significant negative impact on the performance of the protocol. One aspect of the present invention is that it can minimize the impact of harmful protocols while achieving the goal by using a deep table. Conventional prior art mail server components cannot yet provide in-depth tables.

When the mail information store is further divided into mail folders, those mail folders can be organized into hierarchies. Fig. 12 shows an example of the mail folder hierarchy. In FIG. 12, the folder 1204 is a subfolder of the folder 1203. The folder 1203 is again a subfolder of the folder 1202. The folder 1201 is the root folder. The root folder is not a subfolder of any other folder. All other folders are members of the folder hierarchy rooted at folder 1201. Generally speaking, each folder in the folder hierarchy does not directly reference each other folder. A folder may only be able to directly reference its subfolders. The folder can also directly reference any folder that has it as a subfolder. In many cases, each folder may only be directly referenced by the root folder of the hierarchy.

The deep table may contain information about each folder in the folder hierarchy. Each folder may have a row in the deep table. The information in the deep table allows it to be used to determine whether the contents of a mail folder have changed within a certain period of time. A simple comparison between the copy of the folder row at the beginning of the time period and the copy of the folder row at the end of the time period can be used to determine the changes to the mail folder in a specific time period. In one embodiment, each row of the deep table includes the following attributes:

The attributes of the mail folder row in the deep table can be updated when changes are made to the contents of the folder. In order to effectively implement the deep-level table update, the applicant found that it is helpful to quickly and directly quote the deep-level table. At least, the applicant found that there should be small and predictable levels of indirection when trying to access the deep table. For example, positioning the deep table at any level in the folder hierarchy does not provide a predictable number of levels of indirection. For this reason, in an embodiment of the present invention, the deep-level table may be associated with the root folder of the mail information storage folder hierarchy of the mail network user.

The communication between the mail client component and the mail server component can be divided into multiple communication sessions. Loss of mail information store synchronization may occur between sessions, for example, during a network connection interruption. In order to rebuild the mail information store synchronization at the beginning of the communication session, some of the protocols used to communicate with the mail server components of the previous version adopted SynchroFolder ROP for each folder in the folder hierarchy. Generally speaking, the contents of some folders will not change between sessions. A SynchroFolder ROP with an unchanged folder as its target resulted in a "null synch" (null synch). Although "zero sync" does not cause any folder changes to be transmitted to the mail client component, it still has costs associated with it, such as state block data objects, which can be significant.

Figure 13 illustrates an embodiment of the present invention that avoids such "zero synchronization" results by using a deep table. In the first request 1301, the mail client component 501 sends the ROP (for example, GetHierarchyTable) requesting the deep table to the mail server component 502. In the first response 1302, a copy of the deep-level table is provided to the mail client component 501. Generally speaking, the mail client component 501 will have a previous copy of the deep table. The mail client component 501 can quickly determine which folders in the user's mail information store on the mail server component 502 have changed by using a line-by-line comparison of the two copies. Then, use ROP (eg, SynchroFolder) to synchronize only those folders that have changed. The request 1303 and the response 1304 can be repeated as needed to synchronize the changed folders. After successful synchronization, the copy of the mail client component of the deep table can be updated to match the most recent copy sent in response 1302. If the mail client component 501 does not have a previous copy of the deep table, it is possible to synchronize all folders with a row in the latest copy.

Once the synchronization of the user's mail information storage has been established, the synchronization can be maintained by periodically repeating the above-mentioned session initiation step (ie, polling the mail server component), but this solution is disadvantageous. For example, the polling period may be much shorter than the time period between changes in the user's mail information store. In this way, relatively speaking, many in-depth table comparisons will show that no folders have changed. Such comparisons are actually wasteful, so agreements that can avoid them are more effective.

Some mail networks include devices that allow the mail client component to subscribe to be notified by the mail server component when the content of a particular mail folder changes. Some previous versions of the mail client component did use this device to maintain synchronization of the user's mail information store by creating separate subscriptions for each related change notification within the user's folder hierarchy. In an embodiment of the present invention, the mail client component may only create a single subscription for notification of changes related to the deep table. A single subscription is more efficient because fewer ROPs are required to establish it and consume less server-side resources.

13, according to one aspect of the present invention, when the latest version of the mail client component 501 uses GetHierarchyTable ROP in the first request 1301 at the beginning of the communication session with the mail server component 502, the mail client component 501 automatically subscribes to The change notification related to the deep-level table is returned in response 1302. When the mail folder in the user mail information store at the mail client component changes, for example, adding a mail message to the folder, the deep table is updated as described above. The change of the deep level table triggers a notification alarm 1305 to the mail client component 501. Although the notification alert responds to the reservation made by request 1301, it is not part of the explicit request-response cycle. Therefore, the use of the notification system provided by the present invention greatly reduces the overhead of the mail network.

A single booking may result in many notifications. In one embodiment, a connectionless network transmission mechanism is used to transmit the alarm, for example, the user datagram protocol/Internet protocol (UDP/IP) is used, but any suitable network transmission mechanism can also be used. In response to the alarm, the mail client component 501 sends a request 1306 containing ROP (for example, GetNotification) to the mail server component 502. In response 1307, any changed row of the deep table (ie, the row corresponding to the changed folder that triggered the notification) is sent to the mail client component 501. Then, the mail client component 501 uses ROP (eg, SynchroFolder) to synchronize only the changed folders.

Multiple mail client components can be subscribed for notification of changes related to the same data object (eg, the same mail folder), for example, to provide collaboration functions. As shown in FIG. 18, the mail client components 1801, 1802, and 1803 are subscribed for notification of changes related to the same data object (not shown) on the mail server component 1804. The mail client component 1803 sends the ROP 1805 to the mail server component 1804, causing the data object to change. As a result of the change, the mail server component 1804 sends change notifications 1806, 1807, and 1808 to the mail client components 1801, 1802, and 1803. The change notification may carry very little information that cannot identify the changed data object, so that the mail client component may not be able to determine the cause of the change. If the data object is a mail folder, the change notifications 1806, 1807, and 1808 may cause the mail client components 1801, 1802, and 1803 to start synchronizing the changed folders. Since the mail client component 1803 is responsible for the change in this example, the result will be "zero synchronization."

For the reasons discussed earlier, it may be desirable to eliminate the synchronization that causes "zero synchronization". However, the notification behavior is not always undesirable, and certain mail client components may rely on it. One aspect of the present invention is to enable the mail client component to configure the notification behavior of the latest version of the mail server component, so as to improve the protocol performance, and at the same time provide unchanged notification behavior to the previous version of the mail client component.

Figure 19A describes the notification behavior that may be provided by the previous version of the mail server component. Figure 19B depicts a configurable notification behavior in accordance with an aspect of the invention. As needed, the latest mail client component may represent a mail server component that can perform the notification behavior of FIG. 19B, for example, by providing a flag with the request, in the example shown in FIG. 19B, the IGNORE_OWN flag.

In step 1901, the next candidate in the subscriber group to be notified is selected. In step 1904, it is checked whether the reservation has the IGNORE_OWN flag. If the flag does not exist, step 1904 branches to step 1902, where a notification is sent to the candidate subscriber. If the flag is found, step 1904 branches to step 1905, where the subscription is checked again to determine whether the subscriber has triggered the notification. This determination can be made by checking the communication session identifier ("session ID") of the session used to place the subscription. For example, the session ID may include a globally unique identifier and a six-byte serial number. Also check for notifications for the session ID related to the reason. If the two match, the notification is eliminated. The result is that the mail client component that caused the notification will not receive the notification either. Then, the sub-process proceeds to step 1903, as described below.

If the subscriber does not trigger the notification, the session ID related to the subscription will not be the same as the session ID related to the reason for the notification, and step 1905 branches to step 1902, where the notification is sent. Then, the process proceeds to step 1903, where it is determined whether more subscribers are to be notified. If so, the sub-process returns to step 1901, otherwise the sub-process ends.

As described above, a mail client component that uses a cache of mail information may request synchronization of information or other data objects between the local client data store and the data store available at the mail server through, for example, ROP. The mail client component may similarly request that information be copied from the server storage to the client storage. In either case, the fast transfer mode can be used to make the request.

Generally speaking, when requesting information or other data like files for synchronization or copying, the request (eg, ROP) includes an indication of all the information that is desired to be synchronized. The list can be automatically constructed by the mail server component, for example, by using the status block feature described above. For the mail server component of the previous version (prior art), an error in a message or data object in the ROP request will cause the failure of all items in the request. This process is shown in FIG. 14A, in which a request containing ROP (for example, FXPrepare) is sent in step 1401, and a messageID (information identification) group is designated for copying or synchronization. The fast delivery mechanism is established at the mail server component 502, and the fast delivery ID is sent to the mail client component 501 in step 1402. Then, the mail client component 501 requests the copy or synchronization of the data object by including a request such as FXGetBuffer ROP (step 1403). When the mail server component 502 tried to open the requested information, an error occurred in one or more of the information or other data objects. Examples of errors include: corrupted information or data objects, server failures, mail server component 502 storage overflow, or viruses detected for data objects.

After the error, in step 1404, the mail server component 502 sends a fatal ROP error in the data flow to the mail client component 501. In this way, the synchronization fails, the information in the messageID group is not synchronized or copied, and the status block or similar update information is not received by the mail client component 501. Then, the mail client component 501 needs to request synchronization or copy of the data object at another time. It is possible that if the error is not fixed at the mail server component 502, the error message may continue to be sent, and the information in the messageID group will never be synchronized or copied.

According to one aspect of the present invention, instead of the fatal ROP error, the latest mail server component may send error information related to a specific data object (eg, mail information), causing only the synchronization of the data object to fail. This feature allows you to send and synchronize or copy the information or other data objects in the ROP, or other requests even if the response includes information or other data objects with errors.

As an example of how to handle object-specific errors, the latest mail server component may send error messages in the data stream of data objects with object errors. In this example, for ease of reference, the error is called FXErrorInfo. As described further below, as needed, FXErrorInfo may include the following information: the information ID of the data object with the error, and additional information about why the information failed.

Fig. 14B shows a synchronization in which an error occurs in the message M3. This error causes the FXGetBuffer response 1405 to include information M1 and information M2, followed by FXErrorInfo, and then M4. The FXErrorInfo information allows the mail client component 501 to know which information has an error, and synchronize all other information in the response. If the error information FXErrorInfo includes information related to the cause of the error, the client component can act on the information accordingly, for example, by displaying an error message to the user.

The following table shows an example of the possible format of FXErrorInfo:

As shown above, the example format includes version attributes, error codes, and message IDs. In addition, one or more attributes can be added as needed. Also, as described above, an auxiliary field can be defined for transmitting error details. In this way, an attribute (such as an array) can be defined in order to specify the field size of the error details, and a field can be provided, which can be an unstructured array such as used to transmit the error details. As described above, the mail client component 501 can handle the error details as needed.

FXErrorInfo can complete the synchronization of the first response, for example, causing the mail client component 501 to provide status blocks or other information. Since the mail client components are now synchronized through the message M4, the next pair of synchronized requests 1406 may cause the response 1407 to have information after M4 (eg, M5 and M6).

In order to indicate that the mail client component 501 is the latest version, and therefore can process FXErroInfo information, a flag can be defined, for example, FXRecoverMode, which can be sent with the ROP requesting synchronization or copying. Other instructions can be used for the mail client component 501 to inform the mail server component 502 that it can process the FXErroInfo information.

When the mail server component 502 sends one or more information or other data objects to the mail client component 501, attribute tags (for example, ptag) can be used to separate or define the data flow to the mail client component. For example, a list of information may include the start information ptag and the end information ptag of each message. Between the start and end ptag may be an attribute list ptag and a theme ptag, the latter two may have string attributes. The theme ptag can be followed by the theme itself. Other attribute flags can also be included.

In the case of an error when sending information, FXErrorInfo can be provided as a ptag, and may have binary attributes, such as defined by the above table. An example of the following data stream includes both success information and error information. In the case of an error, the end information ptag is not used for the specific information, and ptagFXErrorInfo is the last ptag of the information.

ptagMessageListStartptagMessageStartptagPropListptagSubject [PT_STRING]"Re:Your email"...ptagMessageEndptagMessageStart...ptagFXErrorInfo [PT_BINARY][As described in the table content]

ptagMessageStart...ptagMessageEndptagMessageListEnd FIG. 15A shows the steps used by the mail server component 502 to transfer information to the previous version mail client component 501. Starting from step 1501, the message group is prepared, for example, by placing the message group in a fast transfer data store. In step 1502, the information begins to flow out, for example, immediately after being placed in the sending buffer of the mail server component 502. If an error occurs when the information is flowed out, then in step 1504, the fatal ROP error flows to the mail client component 501. Then the sub-process ends. If there is no error when the information is flowed out, then in step 1503, it is determined whether there is more information in the group. If so, the process loops back to step 1502, where the next message is flowed out. If not, the sub-process ends.

FIG. 15B shows the process of processing the message group by the mail server component 502 of the latest version. The steps taken vary depending on whether the mail client component is the latest version or a previous version. Steps 1501-1504 are the steps used in the previous version of the mail client component, and they are the same as the steps with the same number in the previous paragraph.

If there is an error in the outflow of information in step 1502, it is determined in step 1505 whether the request includes a flag, such as FXRecoverMode. If the request contains this flag, the mail client component 501 is the latest version, and step 1505 branches to step 1506, where FXErrorInfo flows out to the mail client component 501. Then, the process continues to step 1503. If the request does not include the flag, step 1505 branches to step 1504, where a fatal ROP error is issued. Then the sub-process ends.

As shown in the figure, the flag that exists within the request allows the outflow process to continue by allowing the outflow of FXErroInfo instead of failing and sending a named ROP error. The flag is issued by the latest version of the mail client component 501. The previous version of the mail client component did not include this flag, so as described above, the error caused a fatal ROP error.

If necessary, in another embodiment, an error message (for example, FXErrorInfo) may be issued for a specific attribute of the message or other data object, rather than for the entire message. For example, FXErrorInfo can be issued for the body of the message, or FXErrorInfo can be issued for the attachment of the message. Then, the mail client component 501 can synchronize or copy the attributes that are successfully sent without error, and only the attributes with errors are not synchronized or copied.

Sometimes, information or other data objects may be large enough to span multiple FXGetBuffer responses. In order to process this type of information, the mail client component 501 may include re-running logic so that it can process any part of the received information, and then continue to receive further information appropriately after receiving the error information.

From time to time, it may be desirable to provide feedback on the copying or synchronization progress of data objects (e.g., mail messages) to the mail client component. According to one aspect of the present invention, the latest version of the mail client component 501 may indicate that it can handle the progress mode, for example, by sending a flag like PROGRESS_MODE to the mail server component 502 when requesting synchronization or copying of a data object. In response, the latest version of the mail server component 502 may send out a variety of messages along with the message, such as the total size of all messages, the total number of messages, and the total size of each message, or any combination thereof.

For example, as shown in FIG. 16A, for the previous version of the mail client component 501, the mail client component 501 receives the information in response to a fast transfer request (1601 and 1603) for a group of information. In FIG. 16A, information is received in two responses 1604 and 1606. In the previous version of the mail client component 501 using the fast delivery mechanism, no progress indication of the information flowing out to the client is provided.

However, as shown in FIG. 16B, in response to the response 1607 to the message group of the mail client component, the mail server component 502 may provide the total number of data objects to be transmitted and the total size of all data objects to be transmitted. This information is represented by "Pall" in FIG. 16B. The latest version of the mail server component 502 may also provide the size of each message, which is represented by "P1, P2, P3,..." in FIG. 16B. In addition, as needed, the information related to each message and the entire set of messages may include additional information related to whether each message is FAI or actual mail information. In an embodiment, the information indicated by "Pall" in FIG. 16B is always sent in response to a fast transfer request, even when zero data objects are transferred, this is to simplify the processing of the data stream.

The following table shows an example of the format of the size and number of all data objects to be transferred.

As shown above, separate attributes can be defined for the number of FAI data objects, the total size of all FAI data objects, the number of mail messages to be transmitted, and the total size of all mail messages to be transmitted. You can also add other combinations and additional attributes to the format as needed.

The following table shows the format of the size and other information that can be provided to each message.

As shown above, the format includes the size of the next message and whether the next message is FAI.

17A and 17B respectively show the steps of outflowing the information group according to the previous version mail component and the latest version mail component. The steps in FIG. 17A are similar to steps 1501-1503 in FIG. 15A. For FIG. 17B, the PROGRESS_MODE flag is issued by the latest mail client component 501 together with the ROP. After the information group is prepared at step 1701, it is determined whether the flag exists. If so, the total progress data is sent out in step 1702, and the process then proceeds to step 1502, where the first information is flowed out. If the flag does not exist, step 1701 branches directly to step 1502.

After the first information is flowed out, the process continues to step 1703, where it is determined whether the flag is available. If it is, step 1703 branches to step 1704, where the progress data of each message is flowed out. Then, the process continues to step 1503 described above. If the flag is not available, step 1703 branches directly to step 1503.

An example of the data flow of the latest server component is presented below, which sends data to the latest client component. The data flow is similar to the above data flow, except for the ptag (ptagIncrSyncProgressMode) including the progress sum data, the ptag may be, for example, a binary attribute. In addition, for each message, the progress data of each message is provided, for example, ptagIncrSyncProgressModePerMsg.

PtagIncrSyncProgressMode [PT_BINARY][as described in the table content]ptagMessageListStartPtagIncrSyncProgressModePerMsg [PT_BINARY][as described in the table content]ptagMessageStartptagPropListptagSubject [PT_STRING]"Re: Your email"...

ptagMessageEndPtagIncrSyncProgressModePerMsg [PT_BINARY][as described in the table content]ptagMessageStart...ptagMessageEndPtagIncrSyncProgressModePerMsg [PT_BINARY][as described in the table content]ptagMessageStart...ptagMessageEndptagMessageListEnd In the example shown, the ptag includes the progress data (ptag), and the sum of the progress data (ptagMessageListMode) The ptag (ptagIncrSyncProgressModePerMsg) is located at the front of the message list, and is in front of each message respectively. However, the structure of the outgoing data object can be modified so that the progress data can be included in the information or information list. It is also possible to modify the structure of the outgoing data object to completely eliminate the ptag that delimits the information and/or information list.

The mail client component receiving the progress data can use the data to determine the progress of synchronizing or copying data objects from the mail server component, and use the progress data of each message to determine the progress of each individual message. This information can be useful, for example, when monitoring real-time information related to synchronization progress.

In order to store mail messages or other data objects, several different character sets may be used. For example, ASCII is the most commonly used to store English characters. However, ASCII is not enough to store characters in all languages because it is based on 8-bit characters. Therefore, the ASCII code is only used for 256 characters, which is sufficient for English, but not enough for languages with more characters. On the other hand, the Uniform Character Set (Unicode) is a character set that uses 16 bits (two bytes) for each character, so it can include more characters than ASCII. Unicode can have 65536 characters, so it can be used to encode almost all languages in the world. Unicode contains the ASCII character set.

Generally, the previous version of the mail client component 501 has a designated code page, or character set and/or language related to it. For example, a certain version of the mail client component 501 may have a German code page, while another version may have an ANSI code page. Sometimes it is desired that the mail client component 501 receives mail written in a character set other than the specified code page. According to one aspect of the present invention, the latest version of the client component may force the mail server component to provide all mail in Unicode. Once these mails are received by the mail client component 501, the Unicode mails may be converted into the client's code page or kept in the Unicode format.

In order to indicate that the mail client component 501 requires mail to be provided in Unicode, the mail client component 501 can provide a flag such as FORCEUNICODE to the mail server component 502. A request such as ROP can be used to provide this flag. If the mail server component 502 is the latest version, the mail server component 502 can provide the Unicode version of the mail, if available, or can convert the mail information encoded in other character sets into Unicode.

FIG. 20 shows the steps of providing a specific character set for information according to an aspect of the present invention. Starting from step 2001, the mail server component 502 retrieves information from its data store. In step 2002, it is determined whether there is a FORCEUNICODE flag. If it does not exist, step 2002 branches to step 2003, in which the mail server component 502 provides the mail information with the code page specified by the mail client component, and performs conversion as needed.

If the FORCEUNICODE flag is present, step 2002 branches to step 2004, where it is determined whether the information is stored as Unicode. If so, step 2004 branches to step 2005, in which the information is provided to the mail client component 501 in the Unicode character set. If the information is not stored in Unicode, step 2004 branches to step 2006, where the information is converted to Unicode, and then the process continues to step 2005, where the information is provided to the mail client component in Unicode.

The indefinite articles (a and an) and definite articles (the) used in the context of describing the present invention and similar referents should be understood to include both the singular and the plural, unless specifically indicated herein or clearly contradictory to the context. The terms "comprising", "having", "including" and "containing" shall be understood as open terms (ie, meaning "including but not limited to ), unless otherwise specified. The range of values quoted here is only used as a convenient way to individually indicate each independent value falling within the range, unless otherwise specified here, and each independent value is incorporated into the specification as if it is independently quoted here. All the methods shown here can be executed in any appropriate order, unless specifically indicated here or clearly contradictory to the context. The use of any or all of the examples, or the exemplified language (eg, "such as") here, is only to better clarify the present invention, and does not limit the present invention unless specifically required. Any language in the specification should not be understood as any unrequired element essential to the practice of the present invention.

The preferred embodiments of the present invention are described herein, including the best mode known to the inventor for implementing the present invention. After reading the above description, the changes of those preferred embodiments are obvious to those of ordinary skill in the art. The inventor hopes that the skilled person can appropriately adopt such changes, and the inventor intends to practice the present invention in a manner other than those specifically described herein. Therefore, the present invention includes all modifications and equivalents to the main issues cited in the appended claims, which are permitted by the applicable legal basis. In addition, unless specifically indicated here or clearly contradicted by the context, the present invention includes any combination of the above-mentioned elements in all possible variations.