Hi Patrick,
On Oct 7, 2009, at 13:36 , Patrick Ohly wrote:
On Wed, 2009-10-07 at 11:11 +0100, Lukas Zeller wrote:
On Oct 1, 2009, at 15:26 , Patrick Ohly wrote:
Suppose a client wants to start a SyncML session while the server
still
thinks that the client is still running an old session?
That's a very common case, yes.
I believe this is something that has to be handled outside of the
core engine, right?
Yes, the transport code should recognize it is a new session (no ?
sessionID=xxx in the URL in HTTP case) and call OpenSession() for it
instead of feeding the data into the existing session.
We do that, with one limitation (see below).
And the external code should check if a session is lying around
unused
longer than the timeout allows and end it if so. As the engine has
some mechanisms for that, I'll add some session keys to expose it for
the outside code, so it can implement timeout easily.
The problem is recognizing that the new session is from the same
client.
Same IP address (for HTTP) doesn't mean same client (= Device ID), for
example in a multi-user systems.
Why bother at all - as long as you can figure out if it's a new
session or not that is enough - timeout will clean up orphaned
sessions no matter from what device.
We would have to start the new session up to the point when the
client's
Device ID is known, then terminate the old session before starting the
new one. Would that be possible with the Synthesis engine?
Probably yes - you could perform steps (of which each one only
processes one SyncML command (header=1 command) at a time) until the
header is parsed. You can then query the "initialLocalURI" value of
the session key to get the device ID (SyncHdr Target LocURI).
[...] with interesting effects.
What effects? By design, the server should have no problem with this
situation, so I would expect only boring effects :-)
If I remember correctly, the SDK_textdb flushed relevant data only at
the end of the session.
I see. But I think Beat has fixed this some time in July, such that
the TextDB plugin now flushes the DB each time ThreadMayChangeNow is
called, and that happens at the end of every server request/response
(BTW: that change in textDB introduced the recent nonce saving problem).
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
