Re: [coldsync-hackers] Error when using coldsync from inetd.conf

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On Thu, Apr 05, 2001 at 07:27:01PM -0400, Rich Bowen wrote:
> > Alex Tronin wrote:
> > I did a bit of experiments with netsync-ing and I think how it should
> > be done:
> > Coldsync listening to UDP packets should be a separate server.
> > What it does just listens to incoming packets and sends ACKs, nothing
> > else ( it can check if TCP listener is running, in this case it can
> > send NACK).
> > Don't have to be multithreaded - UDP packets are easy to handle.
> > 
> > Another server would be TCP listener,
> > There are three possible options how to make it:
> > 1) to start from inetd.conf
> > 2) have standalone parent server which spawns a child every time there
> > is incoming connection ( like Apache )
> > 3) have true multithreaded POSIX-style server
> > What is the best ? Any opinions ?
> 
> I would think that it would rather depend on how many clients that you
> are serving. If you have people syncing every few minutes, I would think
> that launching it from inetd would be sufficient. If you have multiple
> connections per minute, perhaps it would warrant a forking server. That
> would seem way overkill in every situation that I'm involved in.

	Agreed. IMO a true apache- or sendmail-style server is
significantly more complex than an inetd-based server: if nothing
else, you have to worry about memory leaks, as well as rereading the
site-wide config file when it changes, that sort of thing.
	I'm not saying that it's a bad idea, just that I'd rather get
the simpler version working first.

	I don't think it's possible to write this as a multithreaded
server: ColdSync has to setuid() for each sync, in order to relinquish
its privileges. Plus, as I understand it, the various threads of a
threaded program have access to each other's address space. For
security reasons, I'd feel more comfortable with a forking daemon
(think 'sendmail' (but don't think "sendmail.cf" :-) )).

	One big advantage of having the same daemon handling both the
UDP and TCP parts of the conversation is that it avoids having to have
two different programs trying to talk to each other. It could be
embarrassing if the UDP responder sent an ACK, but the TCP daemon
wasn't willing to take the sync (e.g., because TCP wrappers or PAM
said it wasn't okay).

	Finally, the pilot-link package includes a UDP responder such
as you describe.
	The main advantage of such a daemon, IMHO, would be as a
redirector. I think that when a server receives a wakeup packet from a
Palm, it can send back a different packet saying, "Don't talk to me,
talk to that guy over there." I haven't played around with this,
though, so I don't know what happens then.

	This could be useful on large networks: palm.frobozz.com is
the central sync server, and handles syncing for all 10,000 employees
in the company. Every other machine merely runs a redirector that
says, "Don't talk to me. Talk to 192.168.10.11 (palm.frobozz.com)".

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
	 This isn't Burger King. You can't have it your way.

-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.