3:17 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=6175
Summary: Implement client side Server Alerted Sync handling
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: Undecided
Component: SyncEvolution
AssignedTo: patrick.ohly(a)intel.com
ReportedBy: congwu.chen(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: forrest.zhao(a)intel.com, shuang.wan(a)intel.com,
syncevolution(a)lists.intel.com
Release Milestone: Undecided
With obex/bluetooth as the transport, Server Alerted Sync is used, the sync is
initiated from sync server by a SAN (Server Alerted Notification) request.
Currently SyncEvolution lacks this functionally, this blocks Forrest's Obexd
work because we cannot set up a complete sync session without SAN request
handling.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:17 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|Undecided |P2
Target Milestone|--- |1.0
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 2009-10-22 06:17:30 ---
(In reply to comment #0)
With obex/bluetooth as the transport, Server Alerted Sync is used,
the sync is
initiated from sync server by a SAN (Server Alerted Notification) request.
SAN *messages* were already accepted for starting a sync. Handling of the SAN
message *content* was added in the meantime.
There are two TODOs left:
// TODO: create a suitable configuration automatically?!
We need to decide what the use cases for this are and which kind of servers we
want to support. Nokia PC Suite? iSync? Our own SyncEvolution?!
// TODO: use the session ID set by the server if non-null
Testing of this feature depends on the deciding about the required server
support.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:20 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7213
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:57 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |DUPLICATE
--- Comment #2 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-28 16:57:42 PST
---
*** This bug has been marked as a duplicate of bug 9312 ***
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
12:13 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |
--- Comment #3 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-28 17:13:37 PST
---
Sorry, wrong issue id..
(In reply to comment #2)
*** This bug has been marked as a duplicate of bug 9312 ***
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:43 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #4 from Chen Congwu <congwu.chen(a)intel.com> 2010-03-07 23:43:39 PST
---
(In reply to comment #1)
(In reply to comment #0)
> With obex/bluetooth as the transport, Server Alerted Sync is used, the sync is
> initiated from sync server by a SAN (Server Alerted Notification) request.
SAN *messages* were already accepted for starting a sync. Handling of the SAN
message *content* was added in the meantime.
There are two TODOs left:
// TODO: create a suitable configuration automatically?!
We need to decide what the use cases for this are and which kind of servers we
want to support. Nokia PC Suite? iSync? Our own SyncEvolution?!
Let's support
SyncEvolution first.
// TODO: use the session ID set by the server if non-null
Testing of this feature depends on the deciding about the required server
support.
In SyncEvolution, the session ID in SAN currently is fixed as
"1", because this
part of code is not accessed from syncevo-dbus-server which manages the session
ID. From a command line point of view, the session ID is meaning less and "1"
is OK.
We can support this via querying the session management from dbus server, but
does it has any benefits? (I don't see in SyncEvolution case)
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:16 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2010-03-08 09:16:06 PST ---
(In reply to comment #4)
(In reply to comment #1)
> (In reply to comment #0)
> There are two TODOs left:
>
> // TODO: create a suitable configuration automatically?!
>
> We need to decide what the use cases for this are and which kind of servers we
> want to support. Nokia PC Suite? iSync? Our own SyncEvolution?!
Let's support SyncEvolution first.
We need to define what that means. Does it mean that we expect the SyncML
server contacting us to use the addressbook/calendar/todo/memo URIs, without
looking at the SAN data formats? A new configuration then would be based on the
"SyncEvolution" server template with "syncURL" set to fit the peer.
That's a useful first step. The next step would be to identify several other,
well-known URI names ("contacts", ...) and/or datatypes and map them to our
data sources.
> // TODO: use the session ID set by the server if non-null
>
> Testing of this feature depends on the deciding about the required server
> support.
In SyncEvolution, the session ID in SAN currently is fixed as "1", because
this
part of code is not accessed from syncevo-dbus-server which manages the session
ID. From a command line point of view, the session ID is meaning less and "1"
is OK.
We can support this via querying the session management from dbus server, but
does it has any benefits? (I don't see in SyncEvolution case)
I don't know what the effect of not using the suggested session ID is. I marked
it as a TODO because I saw that the SAN message contains it. Some servers might
depend on it.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:43 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #6 from Chen Congwu <congwu.chen(a)intel.com> 2010-03-10 23:43:17 PST
---
(In reply to comment #5)
> > We need to decide what the use cases for this are and which
kind of servers we
> > want to support. Nokia PC Suite? iSync? Our own SyncEvolution?!
> Let's support SyncEvolution first.
We need to define what that means. Does it mean that we expect the SyncML
server contacting us to use the addressbook/calendar/todo/memo URIs, without
looking at the SAN data formats? A new configuration then would be based on the
"SyncEvolution" server template with "syncURL" set to fit the peer.
Yes, that's what I meant.
That's a useful first step. The next step would be to identify
several other,
well-known URI names ("contacts", ...) and/or datatypes and map them to our
data sources.
That would better be done when we have scenarios/tests with other
external
servers.
I don't know what the effect of not using the suggested session ID is. I marked
it as a TODO because I saw that the SAN message contains it. Some servers might
depend on it.
Checking the spec, I don't think session ID was meant to be used
like this. The
ID is actually used to help the client to identify the same SAN requests from a
server (As the server might sent multiple SAN continuously) and thus only need
to respond to one of the requests.
Again this is not true for SyncEvolution Server at this moment, on the server
side we might first ensure the generated session ID need to be unique.
On the clietn side, I think we can implement like this:
If the SAN request with the same session ID was received within a reasonable
time period (say 1 hour), we should ignore this packet.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:36 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #7 from pohly <patrick.ohly(a)intel.com> 2010-03-11 05:36:15 PST ---
(In reply to comment #6)
> I don't know what the effect of not using the suggested
session ID is. I marked
> it as a TODO because I saw that the SAN message contains it. Some servers might
> depend on it.
Checking the spec, I don't think session ID was meant to be used like this. The
ID is actually used to help the client to identify the same SAN requests from a
server (As the server might sent multiple SAN continuously) and thus only need
to respond to one of the requests.
Again this is not true for SyncEvolution Server at this moment, on the server
side we might first ensure the generated session ID need to be unique.
On the clietn side, I think we can implement like this:
If the SAN request with the same session ID was received within a reasonable
time period (say 1 hour), we should ignore this packet.
I don't think we need to worry about the session ID right now when it is only
meant for detecting SAN resends. That may be necessary when it is sent via a
link with packet loss, but via Bluetooth, the message will be received exactly
once and only be resent when explicitly requested.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:34 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #8 from Chen Congwu <congwu.chen(a)intel.com> 2010-03-12 01:34:41 PST
---
(In reply to comment #7)
I don't think we need to worry about the session ID right now
when it is only
meant for detecting SAN resends. That may be necessary when it is sent via a
link with packet loss, but via Bluetooth, the message will be received exactly
once and only be resent when explicitly requested.
Ok, let's defer it.
The patch is available in mb6175, one thing I found is using SyncEvolution
template, I have to set auth type to "basic" to get it pass. I think the
authentication process with md5 might be problematic, for a first time client,
it does not know the server selected nonce, so it tries with empty nonce, the
server rejects it this time, the problem is it does not let the client retry
but terminate the server side session.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:41 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #9 from pohly <patrick.ohly(a)intel.com> 2010-03-12 06:41:32 PST ---
(In reply to comment #8)
The patch is available in mb6175,
Not merged yet. The patch about "Disable ForceSlowSync if the sync session is
triggered by a remote peer" needs a bit more work. First, the commit message
doesn't explain why this is done and what the pros and cons of the change are.
I remember that we discussed that, but I don't remember the details. Even if
the commit had included a Bugzilla bug number (which I think doesn't exist in
that case), it would still be worthwhile to summarize the discussion.
Second, the patch modifies the signature of sync(), which is the D-Bus
Session.Sync() implementation. In other words, it breaks D-Bus compatibility.
This needs to be solved differently.
one thing I found is using SyncEvolution
template, I have to set auth type to "basic" to get it pass. I think the
authentication process with md5 might be problematic,
It should be disabled when using Bluetooth: the server should get a
mustAuthenticate=false, set username/password to empty temporarily for that
client's sync session and then accept any kind of credentials. Is that not
working anymore?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:43 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #10 from pohly <patrick.ohly(a)intel.com> 2010-03-12 06:42:59 PST ---
(In reply to comment #9)
(In reply to comment #8)
> one thing I found is using SyncEvolution
> template, I have to set auth type to "basic" to get it pass. I think the
> authentication process with md5 might be problematic,
It should be disabled when using Bluetooth: the server should get a
mustAuthenticate=false, set username/password to empty temporarily for that
client's sync session and then accept any kind of credentials. Is that not
working anymore?
Hmm, what I just described is for incoming connections. For a server initiating
a Bluetooth connection, we probably don't disable username/password. Can you
add that?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
2:26 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #11 from Chen Congwu <congwu.chen(a)intel.com> 2010-03-14 20:26:30 PST
---
(In reply to comment #10)
OK, please see the updated patches.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:32 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #12 from pohly <patrick.ohly(a)intel.com> 2010-03-15 00:32:02 PST ---
Merged, with some minor cleanup.
"inited" => "initiated"
"ForceSlowSync" => "PreventSlowSync"
- * Indicates whether this session is initiated via a remote peer or a
local
- * peer.
+ * Indicates whether this session was initiated by the peer or locally.
The peer is always remote. "local peer" is a contradiction. "remote and
local
side" would be possible.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:36 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 2010-03-15 05:36:28 PST ---
When running as HTTP server, it now fails to find an existing config:
[DEBUG] SAN Server ID 'client-test-1' unknown, falling back to automatically
created 'client-test-1_100315133026' config
[DEBUG] SAN sync with config client-test-1_100315133026
[DEBUG] Configuration client-test-1_100315133026 not exists for a runnable
session in a SAN context, create it automatically
Client "deviceId" is 'client-test-1' and there is a
"syncevolution-client-1"
with that remoteDeviceId.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:49 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #14 from pohly <patrick.ohly(a)intel.com> 2010-03-15 05:49:55 PST ---
The problem is that neither PassSan() nor GetHeader() return an error code in
this check here:
int mode = (message_type ==
TransportAgent::m_contentTypeServerAlertedNotificationDS) ? 2 : 1;
if (san.PassSan(const_cast<uint8_t *>(message.second),
message.first, mode) || san.GetHeader()) {
As a result, we end up treating a normal SyncML message from a client as if it
was a SAN message. Mode is 1 here. So this is might be a regression introduced
by SAN 1.1 support (bug #9312). See also the bug #10120.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
midnight
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #15 from pohly <patrick.ohly(a)intel.com> 2010-03-15 06:00:41 PST ---
Congwu, I think you alluded to this problem in your commit message:
commit 12bd955d88d90c91835c55c0d1e01fcbf60118ba
Author: Chen Congwu <congwu.chen(a)intel.com>
Date: Tue Feb 23 17:01:37 2010 +0800
syncevo-dbus-server: accept SAN 1.0/1.1 pacakge (MB#9312)
Also accept SAN 1.1 package, this requres enabling SAN_1_1 build option for
synthesis SDK.
In dbus server, when receving a message with content type 'xml/wbxml', we
can
not think it as a client contact us, it may also be possibly a server
sending
SAN 1.1 package to us; in this case first take it as a SAN package and try
to
parse it, if fails fall back to a normal synchronization message from a
client.
The SAN parsing did not fail as expected in the original implementation,
thus
a patch for synthesis sdk is essential.
But I am running with a libsynthesis that contains the following fix:
Author: Chen Congwu <congwu.chen(a)intel.com> 2010-03-02 05:23:25
SAN 1.0/1.1 generation: check for invalid SAN package
1. We check the 'version' field in the SAN package to match 1.0/1.1/1.2,
otherwise we consider this as invalid.
2. The PassSan API is changed to add a new parameter 'mode', which defaults
to 0 (try both SAN 1.2 and SAN 1.1 if applicable), however user can also
set 'mode' to 1 to try SAN 1.1 only and to 2 to try SAN 1.2 only.
3. workspaceSize is enlarged from 1024 to 1024*30 since we may accept
invalid
resonably large SAN message.
Is that what you meant in the other commit message?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:19 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #16 from pohly <patrick.ohly(a)intel.com> 2010-03-15 06:19:32 PST ---
From "server" branch:
commit d31c3c28eec3358d5d3c18b1e387d748744ffaa8
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Mar 15 14:14:12 2010 +0100
Remove support for accepting SAN 1.0/1.1 (MB #6175, MB #9312)
As mentioned in MB #6175, running as HTTP server no longer worked
because the incoming message was mistaken as SAN message.
This patch solves this by manually reverting the following patch:
commit 12bd955d88d90c91835c55c0d1e01fcbf60118ba
Author: Chen Congwu <congwu.chen(a)intel.com>
Date: Tue Feb 23 17:01:37 2010 +0800
syncevo-dbus-server: accept SAN 1.0/1.1 pacakge (MB#9312)
Automatic revert did not work because some of the code had been
modified in the meantime.
Reverting this might be the final solution, because we don't need to
support incoming SAN 1.0/1.1. Whoever wants to talk with us should
use SAN 1.2.
Congwu, do you agree?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:06 p.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
--- Comment #17 from Chen Congwu <congwu.chen(a)intel.com> 2010-03-15 19:06:43 PST
---
(In reply to comment #16)
Congwu, do you agree?
I agree, it seems commit
978bd912eeba25c169628cae2728f3dfccaa1866 did not work
reliably as expected, we may need to check the alert code to be within 206~210
in addition.
In the meantime, if we can make the assumption that we only accept SAN 1.2
package when contacting us, we can safely revert them.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:16 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #18 from pohly <patrick.ohly(a)intel.com> 2010-03-22 07:16:04 PST ---
(In reply to comment #17)
(In reply to comment #16)
>
> Congwu, do you agree?
I agree, it seems commit 978bd912eeba25c169628cae2728f3dfccaa1866 did not work
reliably as expected, we may need to check the alert code to be within 206~210
in addition.
In the meantime, if we can make the assumption that we only accept SAN 1.2
package when contacting us, we can safely revert them.
Reverted. With that done, I consider this issue resolved.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:16 a.m.
New subject: [Bug 6175] Implement client side Server Alerted Sync handling
http://bugzilla.moblin.org/show_bug.cgi?id=6175
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #19 from pohly <patrick.ohly(a)intel.com> 2010-03-22 07:16:31 PST ---
Let's verify as part of overall testing.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4563
days inactive
4749
days old
syncevolution-issues@syncevolution.org
20 comments
1 participants
participants (1)
-
bugzilla＠moblin.org