cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c

[Daniel O'Connor]

On Tue, 20 May 2008, Maksim Yevmenkin wrote:
> > Why would you be multiplexing it? It's a virtual serial port, pty
> > sounds like a pretty good match. ie I think I am misunderstanding
> > what you are trying to say.
>
> ok, i will give you an example. lets say i have a couple of bluetooth
> devices. lets say device #1 is a handheld and device #2 is some other
> client device that wants to use serial port service on the pc. say,
> its a bluetooth scanner/keyboard/etc. type device that proactively
> connects to the host computer and sends stream of data.
>
> with virtual serial port there is no real need to register two (or
> more) serial port services on the host pc. one could argue that
> rfcomm_sppd(1) should have a configuration file that says
>
> if connected to device #1 { execute sync application }
> if connected to device #2 { dump data }
>
> technically, both devices could use the same serial port service
> registered on the same rfcomm channel on the same host pc. the data
> coming from two different rfcomm connections from two different
> devices. the server bluetooth endpoint just happens to be the same,
> but the server will have two connections and two separate pty's for
> both clients. this is the soft of multiplexing i'm talking about. the
> same will work in client mode too.

OK.

> > Mmm good point :(
> > I was thinking that in server mode it opened the PTY then waited
> > for a connection but that isn't the case..
>
> this is the case. it opens pty first then it does listen/accept/etc.

Huh yes so it does!

> > I am not sure how/why server mode is actually used - I only have
> > experience with devices that are basically using BT as an RS232
> > replacement.
>
> right, there aren't many examples of server mode usage, but i was
> thinking about "serial console" over bluetooth type thing. of course
> it will never be a real serial console, just another out-of-band
> access. could be useful to somebody.

Selfishly, I think it's better to focus on the client stuff - heck I use 
it, so must everyone else ;)

I wonder if the server stuff should be split into a separate program. At 
the moment rfcomm_sppd works perfectly well as a client program (with 
my patch anyway ;) but server mode needs more work to be properly 
useful (IMO) as it needs the config file and ability to exec stuff on 
demand etc..

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20080521/50e11937/attachment.pgp