Hi Patrick,
a while ago we talked about server session timeout handling.
I wrote:
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.
I just have added two new read-only values in the session key:
"lastused" and "timedout".
"timedout" will return true when the session has timed out (was
inactive during the configured timeout period) and should be
terminated (either by just closing it, which will end it with
408=timeout status, or by writing "abortstatus" with a different
status code first if 408 is not appropriate).
"lastused" returns the time when the session thinks it was last used
(i.e. when it has last encountered a SyncML message).
I just pushed it in synthesis indefero branch unilib as bc623aee31
(engine: added "lastused" and "timeout" session keys for server
session timeout handling) along with a few fixes.
Best Regards,
Lukas Zeller
On Oct 7, 2009, at 12:11 , Lukas Zeller wrote:
Hello Patrick,
On Oct 1, 2009, at 15:26 , Patrick Ohly wrote:
In your experience, what are good timeouts for aborting a SyncML
session
in a server when a client stops sending messages?
The default timeout we use is 300 seconds. The implementation of the
server is usually such that the timeout is only checked when a
subsequent session starts, so if there is only a single session, it
can live longer (which is useful when debugging).
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.
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.
One of our observations with suspend/resume tests was that the
Synthesis
HTTP server allowed two simultaneous sessions with the same client,
[...]
Yes, it has to. In case of failed auth, many clients just start a
new session without terminating the previous one. So the server must
be ready to start a new session with a client after every response
(that's why it saves suspend state at the end of every request/
response cycle, and not only at the end of a session).
[...] with interesting effects.
What effects? By design, the server should have no problem with this
situation, so I would expect only boring effects :-)
In SyncEvolution, the whole server only allows one session at a
time at the moment, to avoid such issues a priori.
This might cause problems with clients that start a new session
after failed auth (inevitable on first sync and MD5 auth).
Best Regards,
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
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
