Date: Wed, 21 May 2008 09:32:39 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c Message-ID: <200805210932.40993.doconnor@gsoft.com.au> In-Reply-To: <bb4a86c70805191656m46af1eafo310bb3782459e23d@mail.gmail.com> References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805200845.57007.doconnor@gsoft.com.au> <bb4a86c70805191656m46af1eafo310bb3782459e23d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1255834.XBC80CXTYJ
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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=20
it, so must everyone else ;)
I wonder if the server stuff should be split into a separate program. At=20
the moment rfcomm_sppd works perfectly well as a client program (with=20
my patch anyway ;) but server mode needs more work to be properly=20
useful (IMO) as it needs the config file and ability to exec stuff on=20
demand etc..
=2D-=20
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
--nextPart1255834.XBC80CXTYJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)
iD8DBQBIM2ag5ZPcIHs/zowRAjJoAJwMupdVBzQ2aq43rzZEdqUDVH15HgCeIOWq
yiIatMtl7HsSj4zIa5l8RyA=
=tZgq
-----END PGP SIGNATURE-----
--nextPart1255834.XBC80CXTYJ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805210932.40993.doconnor>