On Tue, 2009-07-28 at 10:31 +0100, Zhao, Forrest wrote:
>>> If OBEX really doesn't support resuming an interrupted connection,
>>> then syncevo-dbus-server would have to check whether the first
>>> message in a new connection is something which matches an active
>>> session. That changes steps 3-7, because the connect cannot be
>>> processed without the message data. A unique ID for the peer would
>>> be useful, but only if it remains constant after a loss of
>>> connection. In HTTP that's not the case, because the same client
>>> might have a different IP after reconnecting.
>> This is not the case for OBEX, either. After the connection is
>> dropped, the OBEX server may reassign the connection ID to another
>> OBEX session.
> But the peer itself has a unique ID that could be used to address it
> in a new connection request, right? Is it the same for USB and
hmm, please read the definition of cmd_connect() at
You may find that connection ID(i.e. cid) is defined as a global variable and
assigned by OBEX server. Please let me if this answers your question.
No, not quite. I'm looking for whatever corresponds to the IP address in
a TCP connect(), or at a lower level the MAC. In case that it makes a
difference, this is from a user space perspective, not inside the
So for initiating an OBEX connection, how do I find the available
devices and choose one of them?
If I was contacted via obexd and Bluetooth, can I find that device again
when it reconnects via USB, without establishing a connection and
exchanging some data?
Senior Software Engineer
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29