[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [coldsync-hackers] Real life experiences with netsync
- To: <coldsync-hackers at lusars dot net>
- Subject: RE: [coldsync-hackers] Real life experiences with netsync
- From: "Rob Bloodgood" <robb at empire2 dot com>
- Date: Fri, 1 Nov 2002 11:36:05 -0800
- Importance: Normal
- In-Reply-To: <1036151465.4206.55.camel@localhost.localdomain>
- Reply-To: coldsync-hackers at lusars dot net
- Sender: owner-coldsync-hackers at lusars dot net
> I am thinking of writing some conduits to allow end users to sync their
> palms with my web applications. For this I am planning to build some
> custom conduits and use coldsync on my web/app server with end-user
> access through netsync.
>
> So I was wondering what peoples' real life experiences are with using
> the netsync functionality of Coldsync. In particular:
Well, *I* got it working. The first problem was getting netsync to actually
work as a daemon for performing netsyncs! It took awhile but I finally came
up with a patch to make it work. It guts large portions of the netsync
code, then installs a simple forking socket accept loop on the tcp socket.
This works fine for local networks, but I needed to connect from several
different states, via modem. So,
First we got the client a static IP.
Next they got a router that allowed one to enter a port number to forward
that had 5 digits (I'm not kidding!).
Then I ran pi-csd to handle the UDP network sync wakeup packets. The trick
was, since I was doing a port-forward to a NAT'd host, the host's ip was
different than the PDAs were configured to connect to. The external ip was
20x.13x.19x.1xx, and the internal ip was 192.168.1.50. So I ran pi-csd like
this at the bottom of rc.local:
pi-csd -h palm -a 20x.13x.19x.1xx > /home/coldsync/pi-csd.log 2>&1 &
and suddenly the PDAs could connect. (The daemon patch strips all of the
UDP logic for netsync-wakeup).
I also found a patch to change the default sync dir semantics so that
coldsync is assigned its own userid, and when a user syncs, his data goes
into a subdir of that coldsync user's homedir:
/home/coldsync/Bob\ Smith
/home/coldsync/ID1
/home/coldsync/ID2
so that the system could then have centralized access to the data conduits
to import the palm DB's to a local MySQL database. After that, standard
database access, from both Perl and ODBC, was a snap.
>
> 1. How scalable is the solution for enterprise use?
Dunno, how big is an enterprise? Will your company pay for your time to
improve the network daemon patch, and bulletproof it? It's worked for me so
for, how are you going to make it work for you? :-)
> 2. How practical is it for end-users, who are often firewalled, to
> access ports 14237 & 14238 over the Internet?
One way to make that happen would be to install a netsync host in a DMZ,
where the host can't reach *ANYTHING* but the netsync ports externally, and
the db host internally.
Another is a simple port forward... NAT gives free firewalling in a sense,
and the dumbass router could manage it after receiving a ROM update to allow
a port number to forward that had 5 digits. <sigh>
> 3. Does the developer community have any positive real life experiences
> of using netsync across the Internet, for anything other than personal
> use?
My app went online this week. In the last year or so I've been developing
this product, the coldsync daemon has never crashed on me once. My conduits
have needed work, but coldsync just skipped by them even when they were
broken... I got a log message instead of a hung process. Once I finally
solved the NAT/portforward/netsync-wakeup problem, I haven't had to work on
coldsync.
> 4. For my application, would it be better not to use netsync, and
> instead provide end-users with conduits for their worksation platforms
> that remotely access my web applications using SOAP or some other http
> based protocol?
I looked into that, but it turns out there weren't going to be any computers
on the floor... just the PDAs. I ended up being happy to get the promise of
access to a phone line. <sigh> But anyway since the whole point, was to get
the PDA records to a central server (where anything can be done with the
data), we simply set coldsync to read the records from the palm and turn
them into database records... all the rest is simple scripts to extract an
Excel spreadsheet, and a Quickbooks .IIF file.
> Any advice/feedback on the above would be greatly appreciated.
I've attached the patch against 2.2.5 to get my version.
Hope this helps!
L8r,
Rob
big_coldsync.patch