Define channel semantics

[bfirsh]

Following on from #22 and #26: I think we need to define the channel semantics. Saying "the ordering depends on the underlying transport you use" isn't helpful for developers who want to build software that is independent of the underlying transport.

For transports that don't guarantee ordering, perhaps we should enforce ordering at the libchan level? Perhaps we should not use transports that have undefined ordering?

Some other things that would be useful to know when developing on top of libchan, regardless of transport:

• Are messages dropped or repeated?
• How reliably are messages delivered? (i.e. given a 100%, 99.99%, 99.9% etc reliable network, what is the reliability of libchan?)
• Are there buffers that can overflow?

@aphyr @shykes @dmcgowan @aanand – thoughts?

(I know little about protocol design, so all credit to @andrewgodwin for thoughts on this.)

[aphyr]

Also: backpressure semantics.

[shykes]

Buffering and reliability definitely require a conversation.

Ordering however is not transport-specific: it must always be guaranteed
within a session. So I think there is no issue there.

On Friday, July 4, 2014, Kyle Kingsbury [email protected] wrote:

Also: backpressure semantics.

—
Reply to this email directly or view it on GitHub
#39 (comment).

[dmcgowan]

I can speak to the spdy transport implementation, since that will be default it may make sense to make its semantics the standard for the protocol in the future. In the spdy transport, the reliability is tied to the reliability of the network, meaning if there is no network outage, the message will be delivered (duplicates are not possible). Any transport which aimed for reliability higher than the network connection reliable I think will be a challenge since it may require extra protocol to make the same guarentees.

Ideally I think we should strive for keeping the channel semantics as close to go channel semantics as much as possible (and practical). This would mean implement backpressure and buffering similar to how it works in go channels, but would require acknowledgement of receive. This acknowledgement may not be practical and I think that is what we need to determine (and does send-side buffering make it more practical?). Error handling will also be a major difference, since go channels cannot return error, only panics when sending on a closed channel. In libchan's case, I think it would be ideal to get an error if a message was not delivered due to a network/transport issue.

[pkieltyka]

btw, with the settling of the http/2 spec and the work by Brad F. at https://github.com/bradfitz/http2 (+ https://http2.golang.org) ... is spdy synonymous in the discussions/plans? I am sure Brad's efforts will yield a robust http/2 implementation for client/server, and I personally don't see the value in anything else spdy related in favour of that. Just wondering..

[dmcgowan]

@pkieltyka the plan is to track spdy which is tracking http/2. Spdy/4 should be compatible with http/2 and allow us to use a standard go implementation. Http/2 does have quite a few changes from spdy/3 but it shouldn't change the behavior of libchan. Only concern would be that any standard implementation requires us to make protocol changes since there may not be direct access to the framing layer. Likely we will keep spdy/3 support as is and add http/2 spdy/4 support as a separate transport possibly with its own protocol definition.