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
signature.asc
Description: This is a digitally signed message part.
