Some thoughts for clarification:
On API level timeout value zero for tlm_replyQuery and tlm_request wil still mean "use default value from given application session" - this is consistent with the existing API and supposedly existing application SW.
Obtaining the infinite timeout is getting to be solved by using 0xFFFFFFFF or better the define TDRP_MD_INFINITE_TIME.
Within the stack the timeout for a Mr/Mq session will be infinte (or at least the infinity the timestruct will offer - rage > 130 years).
On the wire timeout zero for Mr/Mq mean infinity, for Mn/Mp timeout has no meaning and keeps being zero - this needs to get described explicitely within the standard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After revisiting the sandard doing the actual implementation some topics have arised. Basically the infinite timeout may have the use case to open a MD connection - supposedly unicast - where no time for the reply can chosen beforehand. An example may be database query or similar time consuming tasks with unpredictable duration. Leaving this as it is (zero timout within an Mr frame equals "infinity") there is plainly no sense of using an infinite confirmation timeout. Once the reply data are sent, there needs to be an confirmation within limited time. Otherwise there is the risk of havin a session open for indefinite time.
Therefore neither Mq nor Mp will have "infinity" implemented (Mp has no timing anyway).
Another topic is, that infinity will make no sense in UDP messages, as it can not be guaranteed that the message got delivered - only TCP can ensure this task (and is naturally unicast per se).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To check the feature the two binaries rep-testcaller.c and rep-testreplier.c got extended, these have to be considered as experimental coding aid to have the debugger acting as code review helper. See [r1365]
Obviously there is a definite need to generate a TRDP MD test suite, which performs a complete check of the protocol. This was not the aim for these two mentioned programs!
Some thoughts for clarification:
On API level timeout value zero for tlm_replyQuery and tlm_request wil still mean "use default value from given application session" - this is consistent with the existing API and supposedly existing application SW.
Obtaining the infinite timeout is getting to be solved by using 0xFFFFFFFF or better the define TDRP_MD_INFINITE_TIME.
Within the stack the timeout for a Mr/Mq session will be infinte (or at least the infinity the timestruct will offer - rage > 130 years).
On the wire timeout zero for Mr/Mq mean infinity, for Mn/Mp timeout has no meaning and keeps being zero - this needs to get described explicitely within the standard.
Does an infinite timeout makes sense for message data communication? Keeping a session open for all times? What's the use case?
After revisiting the sandard doing the actual implementation some topics have arised. Basically the infinite timeout may have the use case to open a MD connection - supposedly unicast - where no time for the reply can chosen beforehand. An example may be database query or similar time consuming tasks with unpredictable duration. Leaving this as it is (zero timout within an Mr frame equals "infinity") there is plainly no sense of using an infinite confirmation timeout. Once the reply data are sent, there needs to be an confirmation within limited time. Otherwise there is the risk of havin a session open for indefinite time.
Therefore neither Mq nor Mp will have "infinity" implemented (Mp has no timing anyway).
Another topic is, that infinity will make no sense in UDP messages, as it can not be guaranteed that the message got delivered - only TCP can ensure this task (and is naturally unicast per se).
Implemented in the way above in [r1362] - needs a basic test though, [r1363] holds the infinity constant for the API
Related
Commit: [r1362]
Commit: [r1363]
Last edit: mike 2014-11-21
Detected wrap around phenomen for time out calculation - rectified in [r1364]
Related
Commit: [r1364]
To check the feature the two binaries rep-testcaller.c and rep-testreplier.c got extended, these have to be considered as experimental coding aid to have the debugger acting as code review helper. See [r1365]
Obviously there is a definite need to generate a TRDP MD test suite, which performs a complete check of the protocol. This was not the aim for these two mentioned programs!
Related
Commit: [r1365]