search

docker / libchan

Like Go channels over the network
Apache License 2.0
2.47k stars 142 forks source link

Define channel semantics #39

Open bfirsh opened 10 years ago

bfirsh commented 10 years ago

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:

@aphyr @shykes @dmcgowan @aanand – thoughts?

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

aphyr commented 10 years ago

Also: backpressure semantics.

shykes commented 10 years ago

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 notifications@github.com wrote:

Also: backpressure semantics.

— Reply to this email directly or view it on GitHub https://github.com/docker/libchan/issues/39#issuecomment-48070705.

dmcgowan commented 10 years ago

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 commented 9 years ago

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 commented 9 years ago

@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.