http://bugzilla.moblin.org/show_bug.cgi?id=3427
--- Comment #12 from Chen Congwu <congwu.chen(a)intel.com> 2009-07-21 03:34:24 ---
(In reply to comment #11)
So we can register a callback for TransportAgent which will be called
regularly, during the callback in EvolutionSyncClient, we can decide a timeout
and retry. Yes,it looks better.
(CurlTransportAgent/SoupTransportAgent) or at some higher protocol
level? I
think it should be at some higher level, for example the main
EvolutionSyncClient event loop. Because TransportAgent::send() is allowed to
block (curl), some kind of idle callback would be needed to implement this
approach.
It would have the advantage that it only needs to be implemented once and has
better access to context information (timeout settings in configuration,
information about peer) to make policy decisions and/or notify the user.
We need to cover two error scenarios:
* message reached the server, only its reply is lost =>
server must handle duplicate messages
* message never reached the server
Can't we test this with intercepting messages, like we do for the interrupt
tests?
It's not easy to drop reply at client side; for the real case the reply
is
never received so the client is blocking; it can not be emulated by getting the
reply and ignoring it(the client will not block).This can be emulated by a tcp
proxy which reads the request but does not reply.
Duplicate requests in different sessions should have already been covered by
existing interrupt tests; but not duplicate request in the same session. This
can be added of course.
The two scenarios can be tested separately as above, but is not easy to
combine.
I think the message should have reached the server in this case, if the request
sending is not successful, the transport should complain (TCP should work
here), right?
--
Configure bugmail:
http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.