Hello,
the "experiments where devices were disconnected while a session ran
and it continued seamlessly after reconnecting" were with HTTP (e.g.
devices connected to the internet via WLAN, and reconnecting over GPRS
when walking out of WLAN coverage).
I must admit that I don't have a lot of practical OBEX experience, but
IMHO OBEX is used only in scenarios where the connection cannot change
as with HTTP. I'd say if someone pulls the USB cable during a sync,
the session should abort/suspend. Similarily if the device goes out of
BT coverage.
The lower protocol levels of these OBEX connections provide some
degree of data integrity by themselves already to compensate for
intermittent interference etc. If these aren't sufficient, I doubt we
can do much on the higher level.
Furthermore, If I remember correctly, a sync session in OBEX runs
within a single OBEX session anyway (unlike HTTP), so if that
transport level session breaks, a new SyncML session must be started
anyway.
Best Regards,
Lukas
On Jul 30, 2009, at 17:59 , Patrick Ohly wrote:
Hello!
As discussed here in an earlier thread, when clients don't get a reply
to their HTTP POST, they can resend that message and that way work
around half-open TCP connections. It may also be a good idea in case
of
other, detected network problems.
Over on the SyncEvolution list we we are now discussing the
integration
of SyncML with OBEX as part of a Linux desktop. Here the question of
message resending came up again.
With HTTP, clients can be redirected to a special URL which encodes a
session ID. That means messages resent after a loss of connection can
still be matched with the session before parsing the message content.
With OBEX connections, the same thing is not possible: it is not
possible to include meta information when reconnecting, so the SyncML
recipient would have to parse the message before it can determine the
session ID.
The other problem is the question who reconnects. In the normal OBEX
use
case, the desktop runs as SyncML server and connects to the client.
But
the current "resend message by client" error handling would then
depend
on the client being able to connect to the server.
Finally, OBEX would work over USB, Bluetooth and IrMC. A server which
has connected via Bluetooth might come back via USB.
I remember that Lukas mentioned experiments where devices were
disconnected while a session ran and it continued seamlessly after
reconnecting. Was that using HTTP as transport protocol or OBEX? If it
was HTTP, any thoughts on doing the same with OBEX? Hopeless or
doable?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
