> >>> 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 > Bluetooth?
hmm, please read the definition of cmd_connect() at http://git.kernel.org/?p=bluetooth/obexd.git;a=blob;f=src/obex.c;h=53ec9b92c54bed4fac349674060cce10f0658eef;hb=HEAD 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. Thanks, Forrest _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
