Friday, February 4, 2011

limitation of Sync4J to support sync from multiple subnet through proxy

I happened to had a look at AGPL again recently. AGPL is created to prevent people to host a modified open source project. Therefore, developer can not modify the software under AGPL project and deploy it on his own server as ASP. According to Funambol's site, it is said that user is not allowed to modify its source code even if the modification will be open source. I do not know if I understand it in correct way or not. As a programmer, I understood that open source projects need fund support to keep it to be alive.

But, this AGPL topic made me to recall one issue, i ran into when I worked on sync4j (old name of funambol). To describe the issue clearly, I made the following diagram,


As you can see, terminal one and terminal two sync with sync4j server from different sub net and through proxies respectively. Also, because DNS server in different sub net give the sync4j server different host name, terminal one and terminal two will sync to different host names, which are belong to one same physical server. In this case, the sync4j server can receive the sync request. However, it will refuse to process it. Why? Because sync4j use serverUri as part of its authentication protocol. Sync4j will load serverURI from its sync4j.properties configuration file and compare it with localURI from sync client in syncML. Therefore, sync4j server failure on processing the sync message as the serverUri from client side does not match the serverURI from sync4j.properties file.

We can see relevant code from sync4j client native code. In file SyncMLProcessor.cpp, around line 241, we can see some code like this,

uri = getElementContentSaveMem(target, TEXT("LocURI"), NULL, &startPos, &endPos);
        if ((uri == NULL) || (wcsncmp(uri, source.getName(NULL, 0), endPos - startPos) != 0)) {
            //
            // This Sync is for another source
            //
            target  = NULL;
            uri     = NULL;
            continue;
        }


However, it is not difficult to walk around this by modifying its SyncSessionHandler.java. But, this will broke Funambol's AGPL license. Fortunately, in sync4j, many things are configurable. Developer can actually develop their own syncSessionHandler class and registered it into sync4j server.

The above analysis only apply to sync4jServer version 2.3. This post is only based on what I can recall. Probably, it has been changed in new version of Funambol server. I do not have time to check it yet. But, you can pay attention on this unique sync server name requirement from sync4j server if you plan to sync through multiple subnet connected with multiple routers attached to different DNS servers' configurations. Also, BTW, the native sync client API library from Funambol does not support sync through proxy and proxy authentication. When I worked on it, I have to add my own code to support sync through proxy with proxy authentication. But, I am not sure if they have added features to support this in their new release. It will be interesting to have a look at it later.

No comments:

Post a Comment