WO2010069207A1

WO2010069207A1 - Canceling synchronization method and device thereof

Info

Publication number: WO2010069207A1
Application number: PCT/CN2009/074655
Authority: WO
Inventors: 易永健; 李克鹏
Original assignee: 华为技术有限公司
Priority date: 2008-12-16
Filing date: 2009-10-28
Publication date: 2010-06-24
Also published as: CN101753611A; CN101753611B

Abstract

A canceling synchronization method and a device thereof are provided by the present invention. The method includes that: a canceling synchronization notification is generated when the synchronization needs to be canceled (101); and the canceling synchronization notification is sent to the other side of the synchronization, so that the other side of the synchronization can cancel the synchronization according to the canceling synchronization notification (102). The cancel of the synchronization is indicated by a reserved code in the Synchronization Markup Language used in the canceling synchronization notification, or by a control parameter added in the transmission protocol. Thus, the consistency and timeliness of the canceling synchronization operations of the both sides of the synchronization is realized.

Description

Method and device for canceling peers

The present application claims priority to Chinese Application No. 20081024122, filed on Dec. 16, 2008, the entire disclosure of which is incorporated herein by reference. Technical field

The present invention relates to the field of communications, and in particular, to a method and apparatus for canceling a peer. Background technique

In the prior art, SyncML (Synchronization Markup Language) aims to enable end users, device developers, infrastructure developers, data providers, software developers, and service providers to work together to achieve true use. Any terminal device can access any network data anytime, anywhere. A typical application of SyncML is the data peer between mobile devices and network services. In addition, SyncML can also be used for peer-to-peer data peers, such as between two PCs.

In a data peer process, each step may contain multiple messages (MSG), and each message represents a mutual interaction between the peers (such as client->server, or server->client) ). Taking the interaction between the server and the client as an example, after receiving the first message from the client, the server will generate the peer session on the server side (save the account, mode, peer data, etc. of the user this time). Related information), and close the peer session when the client returns the last message (while releasing related resources, recording the same result log).

However, the inventor found in the process of the invention that in the actual application process, the user often actively cancels the data peer operation in the peer process, resulting in interruption of the normal message interaction between the client and the server. At this point, the server will continue to wait for the client to return a message, which will mistake the client's cancellation behavior as a peer timeout and cannot cancel the peer in time. Summary of the invention The solution provided by the embodiment of the present invention is that when the peer is cancelled, the canceling party can notify the peer of the peer, so that the other party can cancel the peer according to the notification.

An embodiment of the present invention provides a method for canceling a peer, including:

When canceling the peer, a cancel cancellation notice is generated;

Sending the canceled peer notification to the peer of the peer, so that the peer of the peer cancels the peer according to the cancel cancellation notice.

Receiving a cancellation notice sent by the other party;

Parsing the cancel peer notification, and identifying cancellation peer control information included in the cancel peer notice;

The peer is cancelled according to the cancel peer control information.

An embodiment of the present invention provides a peer device, including:

a notification generating unit, configured to generate a cancel peer notification when the peer needs to be canceled, and a notification sending unit, configured to send the cancel peer notice to the peer, so that the peer is in accordance with the cancellation歩Notify cancel the same.

An embodiment of the present invention provides a peer device, including:

a notification receiving unit, configured to receive a cancel peer notification sent by a peer of the peer;

a parsing unit, configured to parse the cancel peer notification, and identify cancellation peer control information included in the cancel peer notification;

The cancellation unit is used to cancel the peer according to the cancellation of the peer control information.

The method and device for canceling the peer are provided by the embodiment of the present invention, and the peer of the peer is notified by sending the cancellation cancellation notice, so that the peer of the peer can cancel the peer and release the peer in time after receiving the notification. Related resources, thereby saving system resources. DRAWINGS

1 is a flow chart of a method for canceling a peer in an embodiment of the present invention; 2 is a flow chart of a method for canceling a peer in another embodiment of the present invention;

3 is a schematic structural view of a homophone device in an embodiment of the present invention;

4 is a schematic structural view of a homophone device according to another embodiment of the present invention;

FIG. 5 is a flow chart of a method for canceling a peer in a specific embodiment of the present invention. detailed description

The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

FIG. 1 is a flowchart of a method for canceling a peer in an embodiment of the present invention, including:

101 When the need to cancel the peer, the cancel cancellation notice is generated;

Peer can be between the client (such as a mobile phone, a personal computer, etc.) and the server, or it can be between two servers. When canceling the peer, it means that when the peer party receives the request to cancel the peer, or when a special situation occurs, such as when the memory is full or an error occurs, the cancellation of the peer is performed, and the cancellation of the peer is performed, and Generate a cancel peer notification.

The generated cancellation notice can use the code retained in the peer markup language SyncML; or, use the control parameter added in the transport protocol to cancel the peer. The control parameters can be located in any of the transport protocol header, request parameters, and message body.

In one case, the code generated in the SyncML using the peer markup language is used to cancel the canceled peer notice. In SyncML's existing Special Alert code, 226-250 is reserved code. In the embodiment of the present invention, the cancellation of the peer notification may be adopted 226-

Any of the alarm codes in 250 means to cancel this peer. The alarm code can be included in the message body of the transport protocol. Take HTTP (Hypertext Transfer Protocol) as an example. The message message can be as follows:

<VerProto>SyncML/l .2</VerProto>

<SessionID>K/SessionID>

<LocURI>http://www.syncml.org/sync-server</LocURI>

</Target>

</Source>

</SyncHdr>

<Alert>

<CmdID>K/CmdID>

<Item>

<LocURI>http:〃 www.syncml.org/ sync-server</LocURI>

</Target>

</Source>

</Item>

</Alert>

</SyncBody>

</SyncML>

The special alarm code 226 in <Data>226</Data> indicates that the same party is notified to cancel the synchronization. The above transport protocol can also be other available bearer protocols, such as OBEX (object Exchange protocol, Object Exchange) and WSP (Wireless Session Protocol)

In addition, the cancellation of the peer notification may also use the reserved code indication to cancel the peer in the Status of the peer command. In this way, after receiving the Status, the receiver can know that the other party wants to cancel the peer, and the two parties end the peer operation. Examples of message packets are as follows:

<VerProto>SyncML/l .2</VerProto>

<SessionID>K/SessionID>

</Target>

<LocURI>http:〃 www.syncml.org/ sync-server</LocURI>

</Source>

</SyncHdr>

<CmdID>K/CmdID>

<MsgRef 2</MsgRef

<CmdRe^O</CmdRef

<Cmd>SyncHdr</Cmd>

<TargetRef^http ://www. syncml.org/ sync-server</TargetRef^> <SourceReMMEI: 493005100592800</SourceRef

</Status> </SyncBody>

</SyncML> In the above example, status code 519 indicates that peers are canceled during the peer process. After receiving the cancellation notice, the receiver can perform the operation of canceling the peer by extracting the status code 519 and parsing its meaning.

Alternatively, the generation of a cancellation notification using the added control parameter in the transport protocol indicates cancellation of the peer. The control parameters can be located in any of the transport protocol message headers, request parameters, and message bodies.

The transport protocol can be HTTP, OBEX, WSP, etc. Take the HTTP bearer mode as an example. For example, when you need to cancel the peer, add the control parameter "X-DS-Abort-Sync" to the HTTP header, and set the X-DS-Abort-Sync value to True, indicating that the other party canceled the same class. When you do not need to cancel the peer, do not carry this parameter in the HTTP header or set the X-DS-Abort-Sync value to False.

You can also add control parameters to the HTTP request parameters, such as:

POST

Http:〃 my.ds.com/sync?sid=MS0yMTEuMTM4LjE4NC4yMDE&Abort-Sync=y where Abort-Sync=y is the added control parameter, indicating that the other party is canceled.

In addition, you can also add control parameters to the HTTP message body to notify the other party to cancel the peer. At this time, the message body can have various forms. The examples are as follows:

Example message one:

</SyncML>

Example message two:

</SyncHdr>

</SyncBody>

</SyncML>

Example message three:

</SyncHdr>

</SyncBody>

</SyncML>

Example message four:

The above example message uses the control parameter < 1) 0118 1^/> to notify the other party to cancel the peer. Of course, the control parameters can be determined by the peers and can be expressed in multiple ways.

102 sends a cancel cancellation notice to the peer of the peer, so that the peer of the peer cancels the peer according to the cancel cancellation notice.

After the peer party generates the peer message, the peer notice is sent to the peer party, and the action can be performed before and after the sender performs the action of canceling the peer.

In this embodiment, when the cancellation of the peer is required, the cancellation of the peer notification is sent to the peer of the peer, so that the other party can cancel the peer in time after receiving the notification.

In the embodiment shown in Fig. 1, the peer can also accept the cancel peer response sent by the other party after sending the cancel cancellation notice. The cancellation of the peer response indicates that the other party has successfully canceled the peer. The specific form and content of the cancel peer response message are shown in the embodiment shown in FIG. 2, and are not described herein.

In addition, in a peer-to-peer session, both peers may simultaneously have multiple databases, or perform some non-identical operations, such as exchanging device information of both parties and authenticating information of both parties. In this case, canceling a peer may simply end the peer operation and does not mean ending the peer session and disconnecting the peer. At this point, it is necessary for both parties to indicate or agree whether to terminate the peer relationship after canceling the peer and disconnect the two parties. Therefore, after canceling the peer, you can also perform the disconnection of the peer connection.

When disconnecting the peer connection, the sender of the canceled peer can actively disconnect the peer, or disconnect the peer according to the instructions of the peer.

When the sender of the canceled peer actively disconnects the peer, it is also necessary to instruct the other party to disconnect the peer after canceling the peer. The indication of disconnecting the peer connection may be included in the cancellation of the peer notification; it may also be sent separately, and may be sent separately after receiving the response message, or may be sent before the response message is received.

After sending, the sender can disconnect the peer immediately, or wait until the other party responds before disconnecting the peer. The specific operation can be to close the peer port.

When the indication to disconnect the peer is included in the cancellation of the peer notification, either a code can be used to indicate the two meanings, or a new command can be added to indicate the disconnection of the peer.

If the special alarm code 226 in <Data>226</Data> is used to cancel the peer, it also means to disconnect the peer; similarly, the status code 519, or <1) 0118 1^/> command can also be used. Indicates that the peer is canceled, which also means disconnecting the peer.

When the above code or command only indicates that the peer is canceled, a command may be added to the cancellation of the peer notification to indicate the disconnection of the peer connection, or the notification of disconnecting the peer connection may be separately sent to indicate.

If the <Alert> command can be used to indicate the disconnection of the peer, the message message is as follows:

<Alert>

<CmdID>K/CmdID>

<Item>

<LocURI>http:〃 www.syncml.org/ sync-server</LocURI> </Target>

</Source>

</Item>

</Alert>

The above code may be included in the cancellation of the same notification, or it may be included in <8 1^8 ₀ (1 > as a separate message.

Of course, you can also use the control parameter, <CloseSession>, to indicate that the peer connection is broken. It can be included in the notification to cancel the peer, or it can be sent separately.

Receivers who receive this command can choose to reply or not reply to this message. When you select a reply, you will reply <Status> with a return code of 200 (OK), indicating that you agree to disconnect the peer. The receiver performs the operation of disconnecting the peer connection according to this command, which may be to close the peer port.

In the case of canceling the peer, the anchor values of both peers do not need to be updated, and the original anchor value is maintained. The peer anchor value is mainly used to record the position in the peer process and is used for the resume of the breakpoint. In the case of cancellation of peers, it is difficult for both parties to accurately know where the peers are interrupted. Therefore, in this case, the cancellation process of this cancellation is actually not complete, there is no way to achieve the resume of the breakpoint, and this peer is considered invalid. The next time you are a peer, you will need to re-negotiate and start your peers again from the last completed place.

In this embodiment, the indication of the disconnection of the peer is sent to the other party, and the peer connection is disconnected after the transmission, and the peer-related resources are released in time.

2 is a flowchart of a method for canceling a peer in another embodiment of the present invention, including:

201 receives the cancellation of the same party notification sent by the peer.

Peer can be between the client (such as a mobile phone, a personal computer, etc.) and the server, or it can be between two servers. In the process of peering, when the other party needs to cancel the peer, the cancellation of the cancellation notice sent by the other party is received.

202 parses the cancel peer notification and identifies cancellation peer control information included in the cancel peer notification. The cancellation of the peer notification may use the code retained in the peer markup language SyncML or the control parameter added in the transport protocol to indicate cancellation of the peer. For a specific example, refer to the embodiment shown in FIG. 1. Cancellation of peer information indicates that canceling the peer information is canceling the peer control information, that is, canceling the peer control information may include: canceling the same in the peer notification to indicate the cancellation of the same peer markup language SyncML Or; a control parameter added to the transmission protocol that cancels the peer notification to indicate cancellation of the peer. When parsing the peer notification, it is necessary to identify the information from the parsed message.

203 cancels the peer according to the canceling the peer control information.

The specific operation of canceling the peer can be to stop the operation of the peer only. The two parties can still maintain the peer connection, and the peer port is not closed, but the peer operation is no longer performed.

In this embodiment, the peer cancellation operation is performed by parsing the cancel peer notification sent by the peer, and the consistency between the peers in canceling the peer is achieved, so that the peer-related resources are released in time.

In the method for canceling the peer shown in FIG. 2, after canceling the peer operation, the canceling peer response may be sent to the sender canceling the peer notification, and the cancel peer response notification may be sent as a message. Use the code retained in the peer markup language SyncML; or, use the control parameters added in the transport protocol to indicate that the peer has been successfully canceled. The control parameters can be located in any of the transport protocol message headers, request parameters, and message bodies.

In SyncML's existing Special Alert code, 226-250 is reserved. In the embodiment of the present invention, the cancellation of the peer response may indicate that the peer has been successfully cancelled by using any of the alarm codes 226-250, but the code used in the embodiment of FIG. 1 is required to notify the other party to cancel the peer. the difference. The alarm code can be included in the message body of the transport protocol. Take the Hypertext Transfer Protocol (HTTP) as an example. The message message can be as follows:

Example message one:

<VerProto>SyncML/l .2</VerProto>

<SessionID>K/SessionID>

<LocURI>http:〃 www.syncml.org/ sync-server</LocURI></Source>

</SyncHdr>

<CmdID>K/CmdID>

<MsgRe^2</MsgRef <CmdRef 0</CmdRef

<Cmd>SyncHdr</Cmd>

<TargetRef^http ://www. syncml . org/ sync-server</TargetRef^>

<SourceReMMEI: 493005100592800</SourceRef

</SyncBody>

</SyncML>

Example message two:

The <0 1 >200</0 1 > in the example message one and the code 200 in the example message 2 indicate that the peer has been successfully cancelled. The above transport protocols may also be other available bearer protocols, such as OBEX and WSP.

Alternatively, the cancellation of the control parameter added to the transport protocol in the peer response indicates that the peer has been successfully cancelled. The control parameters can be located in any of the transport protocol message headers, request parameters, and message bodies.

The transport protocol can be HTTP, OBEX, WSP, etc. Take the HTTP bearer as an example. If the control parameter "X-Abort-Sync-Result: 200" is added to the HTTP header, it means that the peer has been successfully canceled.

You can also directly use the status code of the HTTP message to indicate the cancellation result, such as "HTTP/1.1 200 OK", indicating that the peer has been successfully cancelled.

In addition, you can also add control parameters in the HTTP message body, such as < 1)0118 1^0 /> to indicate that the peer has been successfully canceled.

In this embodiment, by canceling the cancellation of the peer response to the sender that cancels the peer notification, it indicates that the peer has been successfully canceled, and the mutual interaction between the peers when canceling the peer is implemented, so that the initiator of the peer is canceled. You can keep abreast of the execution of your peers.

In the method of canceling the peer shown in FIG. 2, after the cancellation of the peer operation, the sender canceling the peer operation and recording the cancellation of the peer notification may also be recorded. Specifically, it is recorded in the log, and it is possible to record the cancellation of the same operation as the other party cancels the peer. For example, if the client sends a cancel notification to the server, the server can record the cancel peer operation in the log after canceling the peer operation according to the notification, which can be recorded as: "The client cancels the peer"; Similarly, after the client cancels the cancellation according to the canceled peer notification sent by the server, the cancellation of the same operation can be recorded in the log as: "Server cancels the peer".

In addition, you can also disconnect the peer connection after canceling the peer. When disconnecting the peer connection, the receiver that cancels the peer notification can also actively disconnect the peer or disconnect the peer according to the instructions of the peer.

When the receiver that cancels the peer notification actively disconnects the peer, it also needs to instruct the other party to disconnect the peer after canceling the peer. Specifically, the cancel peer response may include an indication to disconnect the peer connection, or the receiver canceling the peer notification separately sends a notification indicating that the other party disconnects the peer.

The receiver that cancels the peer notification can use the <^11> command in the cancel peer response to indicate the disconnection of the peer connection, or the <AbortSyncOK/> command definition has successfully canceled the peer and indicates the disconnection歩 Connect. Of course, you can also send a separate notification, using the <^11> command or status code to indicate that the peer connection is broken. An example of using the <Alert> command can be seen in the description of the embodiment as shown in FIG.

An example of using a status code to disconnect a peer connection in a notification to disconnect a peer is as follows: <SyncBody>

<!->

<!->

</Status>

</SyncBody>

In the above example, the receiver uses <81 8> to send back an error response, such as a return code of 520, indicating that the session is abnormal and disconnects the peer. The receiver can perform the disconnection of the peer connection after sending the response, specifically by closing the peer port.

In this embodiment, the receiver that cancels the peer notification is sent to the opposite party by sending an indication of disconnecting the peer, and disconnects the peer after the transmission, and releases the network resource in time.

FIG. 3 is a schematic structural diagram of a homophone device according to an embodiment of the present invention, including:

The notification generating unit 301 is configured to generate a cancel peer notification when the peer needs to be canceled; specifically, when the peer device receives the request to cancel the peer, or when a special situation occurs, such as when the memory is full or an error occurs When the peer needs to be canceled, the notification generation unit generates a cancellation cancellation notice.

The generated canceled peer notification can use the code reserved in the peer markup language SyncML to indicate cancellation of the peer; or, by adding control parameters to the transport protocol, cancel the peer. See the example in 101 for details.

The notification sending unit 302 is configured to send the canceled peer notification to the peer of the peer, so that the peer of the peer cancels the peer according to the canceled peer notification. The peer device in this embodiment sends a cancel cancellation notice to the peer of the peer when the peer needs to be canceled, so that the other party can cancel the peer in time after receiving the notification.

The peer device may further include a response receiving unit 303 for receiving a cancel peer response sent by the peer. In order to realize and interact with the other party, it is timely to understand the execution of canceling the peer operation.

In an embodiment, the notification generating unit 301 may simultaneously include an indication of disconnecting the peer connection in the cancellation of the peer notification when the cancel cancellation notification is generated, and the indication may be used to indicate the cancellation of the retention code or control of the peer. The parameter is used to indicate that the cancellation of the same code or control parameter indicates that the cancellation of the peer and the disconnection of the peer are two layers; it can also be used with a reserved code or control that is different from the reserved code or control parameter that indicates cancellation of the peer. The parameter indicates that the cancellation of the same notification includes a reserved code or control parameter indicating cancellation of the peer, and a reserved code or control parameter indicating that the peer connection is disconnected.

In another embodiment, the indication to disconnect the peer connection may be sent using a separate notification message. At this time, the notification generating unit 301 is further configured to generate a notification for instructing the other party to disconnect the peer connection, and the disconnected peer connection notification is independent of the cancellation of the peer notification. For specific implementation, reference may be made to the description in the embodiment of FIG. 1.

The notification sending unit 302 is further configured to send the notification indicating that the other party disconnects the peer connection. That is, the notification to disconnect the peer can be sent independently of the cancellation of the peer notification.

Additionally, the peer device can also include a disconnect unit 304 for disconnecting the peer. Here, disconnecting the peer connection means disconnecting the peer's data after stopping the transmission of the peer data. The specific operation may be to close the peer port, so as to release the network resources related to the peer in time.

FIG. 4 is a schematic structural diagram of a peer device according to another embodiment of the present invention, which specifically includes: a notification receiving unit 401, configured to receive a cancel peer notification sent by a peer of a peer; the cancellation peer is notified by the peer Send, can be sent as a message, can use the special alert code retained in the peer markup language SyncML; or, through the transport protocol header or transport protocol Adding a control parameter to the request parameter or the transport protocol message body means canceling the peer. See the specific implementation

An example from 101.

The parsing unit 402 is configured to parse the cancellation peer notification, and identify cancellation peer control information included in the cancellation peer notification;

The parsing unit identifies that the cancel peer control information included in the cancellation peer notification is specifically: identifying a code retained in the peer markup language SyncML included in the cancel peer notice; or identifying the cancellation included in the cancel peer notice Control parameters added in the transport protocol.

The special alert code 226 as described in 101 is identified, or the control parameter X-DS-Abort-Sync=tme carried in the HTTP header, or the control parameter Abort-Sync=y carried in the HTTP request parameter.

The cancellation unit 403 is used to cancel the peer according to the cancellation of the peer control information.

The cancel peer unit 403 can read the meaning of the cancel peer control information identified by the parsing unit 402, and perform the operation of canceling the peer according to the control information.

It is also possible that the reception parsing unit 402 performs an instruction to cancel the peer operation according to the execution of canceling the transmission of the peer control information, and performs an operation of canceling the current peer according to the instruction. To cancel the peer's specific operation, you can close this peer session and release the resources of this peer.

The peer device provided by the embodiment of the present invention performs the cancellation of the peer operation by parsing the cancel peer notification sent by the peer, thereby realizing the consistency between the peers when canceling the peer, so as to release the peer-related resources in time. .

The peer device may further include a response generating unit 404, and the response generating unit 404 is configured to generate a cancel peer response, and the cancel peer response may use the code retained in the peer markup language SyncML; or, by Adding a control parameter to the transport protocol indicates that the peer has been successfully cancelled. For details of the cancellation peer response, please refer to the description of the embodiment shown in FIG. 2. The response transmitting unit 405 transmits a cancel peer response to the peer.

In this embodiment, by canceling the cancellation of the peer response to the sender that cancels the peer notification, it indicates that the peer has been successfully canceled, and the interaction between the peers when canceling the peer is realized. When the response generation unit 404 generates the cancel peer response, the indication of disconnecting the peer connection may be included in the cancel peer notification, and the indication may be represented by a reserved code or a control parameter indicating that the peer has been successfully canceled, that is, Indicates that the retention code or control parameter of the peer has been successfully canceled and indicates that the peer has been successfully canceled and the other party is disconnected from the peer connection. It is also possible to use a reservation that is different from the reserved code or control parameter indicating that the peer has been successfully canceled. The code or control parameter is used to indicate that the cancellation of the same notification includes a reserved code or control parameter indicating that the peer has been successfully canceled, and a reserved code or control parameter indicating that the peer connection is disconnected.

In addition, in an embodiment, the response generating unit 404 may be further configured to generate a notification indicating that the other party disconnects the peer connection, and the instructing the other party to disconnect the peer connection notification is independent of the cancel peer notification. See the description in the embodiment of Fig. 2.

The response sending unit 405 is further configured to send the notification indicating that the other party disconnects the peer connection. That is, the notification indicating that the other party disconnects the peer connection is independent of the cancellation of the peer notification transmission.

The peer device can also include a disconnect unit 406 for disconnecting the peer. Here, the disconnection of the peer connection means that after the transmission of the peer data is stopped, the peer connection is disconnected, and the peer port is closed, so that the resources related to the peer are released in time.

The peer device shown in Fig. 4 may further include a recording unit 407 for recording the cancellation of the same operation. The recording unit is specifically used to record the cancellation of the same operation as the other party cancels the peer. Specifically, it is recorded in the log, and it may be that the cancellation of the same operation is recorded as the other party cancels the peer. For example, if the client sends a cancel notification to the server, the server can record the cancel peer operation in the log after canceling the peer operation according to the notification, which can be recorded as: "The client cancels the peer"; Similarly, after the client cancels the cancellation according to the canceled peer notification sent by the server, the cancellation of the same operation can be recorded in the log as: "Server cancels the peer".

FIG. 5 is a flow chart of an embodiment of a method for canceling a peer in accordance with the present invention. Includes:

501. One party A of the peer detects that it is necessary to cancel the peer and perform the cancellation of the peer operation. A can be either a client or a server. It may be that the client detects that the user cancels the peer or the device itself needs to cancel the peer. For details on how to cancel the peer notification message, see the example in 101.

502. A generates a cancellation cancellation notice.

For details on how to cancel the peer notification message, see the example in 101.

503. Send a cancellation notice to the other party B.

B can be either a server or a client.

504. After receiving the cancellation cancellation notice, B parses the cancellation cancellation notification, and extracts control information indicating cancellation of the cancellation.

505. B performs the cancel peer operation according to the control information, and records the operation as “A cancels the same”.

Cancelling peer actions includes closing peer sessions and releasing related resources.

506, B sends a cancel peer response to A.

Cancelling a peer response indicates that the peer has been successfully cancelled. The specific form of the response message is described in detail in the embodiment shown in FIG. 2, and details are not described herein again.

507, A sends a disconnected peer connection notification to B.

508, A disconnects the peer, specifically to close the peer port.

The above execution order may also be other sequences, for example, A may perform the cancellation of the peer operation after sending the cancel peer notification or receiving the cancel peer response.

In this embodiment, when the peer of the peer needs to cancel the peer, the party cancels the notification to the peer of the peer, and the other party returns to cancel the peer response according to the peer notification, and then the peer response is realized. Both parties cancel the consistency and interactivity of peer-to-peer operations in order to release relevant resources in a timely manner and improve the accuracy of peer behavior analysis. It is avoided that one party cancels the same class, and the other party does not know that the act of canceling the peer is mistakenly treated as a peer timeout.

It should be noted that the embodiment of the present invention does not need to introduce independent functional components, and can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technique of the embodiment of the present invention The portion of the invention that contributes in nature or contributes to the prior art may be embodied in the form of a software product stored in a storage medium, including instructions for performing the methods described in various embodiments of the present invention. . The storage medium referred to herein, such as the ROM/RAM and the magnetic assembly, is only a preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim

A method for canceling a peer, characterized in that it comprises:

When canceling the peer, a cancel cancellation notice is generated;

2. The method of claim 1, wherein the canceling the peer notification uses the code reserved in the peer markup language to indicate cancellation of the peer; or, by adding the control parameter to the transport protocol, canceling the peer.

3. The method according to claim 1 or 2, further comprising:

Receiving the cancel peer response sent by the peer.

The method according to claim 1 or 2, further comprising: actively disconnecting the peer connection, and instructing the other party to disconnect the peer connection or send the disconnected peer connection in the cancel peer notification The notification instructs the other party to disconnect the peer.

The method according to claim 1 or 2, further comprising: receiving an indication of disconnection of the peer connection sent by the peer, and disconnecting the peer connection according to the indication.

6. A method of canceling a peer, characterized in that it comprises:

Receiving a cancellation notice sent by the other party;

The peer is cancelled according to the cancel peer control information.

7. The method according to claim 6, wherein the canceling the peer control information comprises: a code retained in a peer markup language, the reserved code being used to indicate cancellation of a peer; or, in a transport protocol The control parameter added to indicate the cancellation of the peer.

8. The method of claim 6, further comprising: recording the cancellation of the peer operation and the canceling the sender of the peer notification.

9. The method of claim 6, further comprising: generating a cancel peer response and transmitting a cancel peer response to the peer.

10. The method according to claim 9, wherein the canceling the peer response uses the code retained in the peer markup language SyncML to indicate that the peer has been successfully canceled; or, by adding a control parameter to the transport protocol, Successful cancellation of peers.

The method according to any one of claims 6-9, further comprising: actively disconnecting the peer connection, and instructing the other party to disconnect the peer connection or send the disconnection in the cancel peer response The notification of the peer connection instructs the other party to disconnect the peer.

The method according to any one of claims 6-9, further comprising: receiving an indication of the disconnection of the peer connection sent by the peer, and disconnecting the peer connection according to the indication .

13. A homogenous device, comprising:

14. The peer device of claim 13, wherein the canceling the peer notification uses a code reserved in the peer markup language SyncML to indicate cancellation of the peer; or, by adding a control parameter to the transport protocol, canceling Peer.

The peer device according to claim 13 or 14, further comprising: a response receiving unit, configured to receive the cancel peer response sent by the peer of the peer.

The peer device according to claim 13 or 14, wherein the canceling the peer notification further includes an instruction to disconnect the peer.

The peer device according to claim 13 or 14, wherein the notification generating unit is further configured to generate a notification indicating that the peer is disconnected from the peer;

The notification sending unit is further configured to send the notification that the peer is disconnected from the peer.

18. A homogenous device, comprising: a notification receiving unit, configured to receive a cancel peer notification sent by a peer of the peer; a parsing unit, configured to parse the cancel peer notice, and identify cancellation peer control information included in the cancel peer notice;

19. The peer device of claim 18, wherein the cancel peer control information comprises: a code retained in a peer markup language, the reserved code being used to indicate cancellation of a peer; or, Control parameters added in the transport protocol to indicate cancellation of peers.

20. The homophone device of claim 18, further comprising:

a recording unit, configured to record the cancellation of the same operation and the sender of the cancellation of the cancellation notice.

The homophone device according to any one of claims 18 to 20, further comprising: a response generating unit, configured to generate a cancel peer response;

The response sending unit is configured to send the cancel peer response to the peer of the peer.

22. The peer device of claim 21, wherein the cancel peer response uses a code reserved in the peer markup language SyncML to indicate that the peer has been successfully cancelled; or by adding a control parameter to the transport protocol. Indicates that the peer has been successfully cancelled.

23. The peer device of claim 21, wherein the canceling the peer response further comprises indicating to disconnect the peer connection.

The response device according to claim 21, wherein the response generating unit is further configured to generate a notification that the peer is disconnected from the peer connection; the response sending unit is further configured to send the The notification indicating that the peer is disconnected from the peer.