Separate control messages cause complexity and bugs

[huitema]

The first integration trials of the "subscribe intent" in the prototype client failed when the source started at group 100, object 0. They did succeed when starting at group 0, object 0. The unit tests for starting with group 1, object 0 also succeeded. This is probably due to an issue with the state machines implemented in clients, relays and origin. A synchronization issue of some kind caused the relay to either not receive or not send the "start point" message that announced the change of origin. The clients then was waiting for object 0/0, that never came.

The immediate cause is probably a missed synchronization point in some condition. But the root cause is complexity. Publishing a media requires three messages:

• POST message, to which the server replies with ACCEPT
• START POINT message, sent after receiving ACCEPT when the transmission does not start at 0/0
• CACHE POLICY message, sent after receiving ACCEPT when real time cache pruning is required.

Those three messages must be received and forwarded by relays, which creates complexity. For example, a client that subscribe to the relay may receive data after the POST is accepted by the relay, but may receive the START POINT message later or not at all. This complexity must be reduced.

The proposal is to merge the START POINT and CACHE POLICY message into the POST message, so the relays will receive a single event instead of three. The cache policy and the initial group ID would be passed as source properties in the publish source API. The change could be combine with a fix to issue #73, merging the "publish" and "post" API on the publisher.

[suhasHere]

+1 on merging these things

[huitema]

Should be solved by PR #101. Will need to reopen if the issue repeats.