Tickets :: Comment on [#12506] Contacts sync with ActiveSync get duplicates and not sync

* Your Email Address
* Spam protection	Enter the letters below: . . . ..__ . . \|\/\| \| \|[__)\|__\| \| \|\__\|\__\|\| \\| \|
Comment	>> Later, as the client device does not see any reply for these entries >> it tries to upload them again and again and again... dups detected, >> of course, but this is bad. > > Well, from what you told me earlier, your device is not receiving > any response from the server before it closes the connection. It > doesn't matter what response we send if the client never sees it. > >> Looking at EAS docs maybe a Status 7 should be replied? >> http://msdn.microsoft.com/en-us/library/gg675457%28v=exchg.80%29.aspx >> === >> 7 > > No, STATUS_CONFLICT is only to be used with an item successfully > synced by the client (the client knows the item's server-side UID) > that has changed on both the client and server. > > What probably should happen is when a duplicate addition is detected > we should return the existing item's UID as if the addition was > successful. Of course, I have no idea what your client will do with > this, since it is demonstrating broken behavior anyway, not to > mention if the connection continues to timeout, this won't help your > original problem anyway. As I said before uploading hundreds of new > messages from the client to the server is NOT something the protocol > was originally designed to handle. > >> On the other hand, it seems interesting that if the Android device >> doesn't see any status reply for some items it behaves like if they >> were not accepted by the server and try again. > > No, in fact it's the exact opposite (though I agree the spec doesn't > make much sense here). From MS-ASCMD 2.2.3.7: > > == > The server is not required to send an individual response for every > operation that is sent by the client. The client only receives > responses for successful additions and fetches, and failed changes > and deletions. When the client does not receive a response, the > client MUST assume that the operation succeeded unless informed > otherwise. > == > > So, no, the client should NOT resend an item if it does not receive > ANY status response. Of course, for client -> server additions the > behavior of any further actions would be undetermined since the > client would not know the server's UID. Rather, from what you told me > earlier, your client is resending the messages because it did not > receive ANY response before the connection was closed. > >> Maybe this could be >> used for pacing the client uploads. > > No. As stated earlier, there is no paging of the client uploads in > the EAS protocol. Attempting to abuse some status code that should > have another meaning is nothing more that a hack to get around broken > client behavior. > >
Attachment
Watch this ticket

Saved Queries