Re: problem with IOBluetoothRegisterForFilteredRFCOMMChannelOpenNotifications()
Re: problem with IOBluetoothRegisterForFilteredRFCOMMChannelOpenNotifications()
- Subject: Re: problem with IOBluetoothRegisterForFilteredRFCOMMChannelOpenNotifications()
- From: "Daniel Birns" <email@hidden>
- Date: Tue, 17 Apr 2007 09:48:23 -0700
I implemented a workaround which works okay: I set a global if I'm doing an async outward-bound connection, and check that in the callback. It's non-optimal, because there's timing holes: if someone does tries an inward bound connection at the same time we try an outward bound, I'll ignore the inward bound connection in the callback. However, it looks like we have timing holes anyway, so this should do for now.
--Daniel
On 4/16/07, Bruce Bernstein <email@hidden> wrote:
Hi Daniel,
One issue here is that if an address/port combination on the queue is invalid, then it will mess up subsequent session opens. You should avoid having a dartcomm with all zeros on the queue, unless it is the currently listening one. It there's a possibility that you can service multiple incoming connections between scans of the event queue (which sounds like a possibility to me in this case...), then this violates a timing assumption I've made and I have to figure out how to fix it. If you are loading the listening dartcomm with the address of the outgoing connection, this will definitely fail since when the event reenters the OPEN_COMM_SESSION_PENDING state it will find the wrong dartcomm to use. If, OTOH, you get a connect notification with zeros for the address if the callback is caused by an outgoing connection, that's easy to filter on. I don't yet have a complete picture of what's going on.
Bruce
Daniel Birns wrote:
>
>
> On 4/16/07, *Bruce Bernstein* <email@hidden
> <mailto:
email@hidden>> wrote:
>
> Hi Daniel,
> One question about this, since I'm curious how this is messing up
> our code (it really shouldn't, since no data will come in on the
> "incoming" pdc and it should get deleted after a timeout)
>
>
> Hmmm -- well what happens is that I think I have an good accept, but the
> address comes out as as zeroes. Also, it seems to mess up the incoming
> socket because I register a callback for it, which does come in as a
> open complete, but with an address of zeroes and I wind up deleting it.
> In other words, what seems to happen is that the outgoing connection
> completes but internally I think it's a failed incoming one.
>
> - Where are you getting the partner's address from to load into the
> dartcomm's Bluetooth address field? If it's the same as the outgoing
> address,
>
>
> that's what it is -- actually it coming from btbuddy.txt right now
> because that's what I'm trying to get working, but I've seen this
> problem sporadically when doing a discover...
>
> you could filter it, but you would have to pass in the queue header
> as your context rather than the listening dartcomm as you are doing
> now.
>
>
> Yes, I can probably work around this somehow like this, but first I'd
> like to see if anyone at apple can tell me what I'm doing wrong, because
> this behavior seems wrong given the calls I'm making.
>
> Bruce
>
>
> Daniel Birns wrote:
> > All,
> >
> > Here's how I call this function:
> >
> > if (!(listenerRef =
> > IOBluetoothRegisterForFilteredRFCOMMChannelOpenNotifications(
> > NotificationCallback, this, channelID,
> > kIOBluetoothUserNotificationChannelDirectionIncoming)))
> >
> >
> >
> >
> > The problem is that the notifier callback is being called when I do an
> > outbound connect to another device. That outbound connect is done
> with
> >
> > IOBluetoothDeviceOpenRFCOMMChannelAsync()
> >
> >
> >
> > I don't know why this would be happening, but our code gets everything
> > wrong an outbound connections, because we start processing an inbound
> > connection that actually doesn't exist.
> >
> > Any advice?
> >
> > --Daniel
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden