rfcomm_sppd -S as generic wrapper

[Helge Oldach]

Maksim Yevmenkin wrote on Tue, 13 May 2008 19:05:20 +0200 (CEST):
> > BTW, Luigi's pipe application is interesting, but what about true
> > two-way communcation? For instance, I would like to have something like
> >
> > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md"
> >
> > ...meaning: Upon receipt of a SP connection request from myPalm we would
> > fork coldsync to synchronize the Palm (just like USB or serial sync, but
> > now bluetooth).
> >
> > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the
> > request terminates.
> 
> well, i thought about this, but not really sure how to do it cleanly.
> here is what i mean. with rfcomm_pppd(8)  (lan service wrapper) we
> only need to start one server and register one lan service with local
> sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and
> starts separate ppp(8) instance that handles this particular client.
> this model works well (imo) here.
> 
> i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you
> seems to be suggesting is that a single rfcomm_sppd(8) instance can
> only handle single client at a time. this could be a reasonable
> assumption.

Good point. However rfcomm_sppd can distinguish different BT peers
already, wouldn't that work by starting a separate rfcomm_sppd for each
BT peer?

> > I'm currently doing this in two separate steps, first starting
> > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty.
> > So yes, this definitely works.
> 
> also your idea about putting rfcomm_sppd(8) entries into /etc/ttys
> should work as it is, no? did you try to put rfcomm_sppd(8) into
> /etc/tty entry for the pseudo terminal (slave) part and run coldsync
> on mater pty?

Yes, it works. But I'd also have coldsync in /etc/ttys, similar to

palm	"/usr/local/bin/coldsync -t serial -s -md"	unknown on

Hmm. Thinking about it, indeed in my case coldsync is the "getty
replacement". Putting rfcomm_sppd into /etc/ttys is merely a hack,
working around the fact that it terminates after each session. So
rfcomm_sppd should probably have some "service selection" mechanism,
similar to what pppd does.

I know I could do my Palm sync task running network sync via TCP via
PPP, however that's a fair bit of overhead. PalmOS can talk serial
natively, so why not use that straight away? Actually "network sync" is
essentially a 1:1 copy of serial sync (which was invented first), as is
USB sync.

Regards,
Helge