Re: [SyncEvolution] SyncML + OBEX

> >>> 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=53ec9b... 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.