Closed aphyr closed 10 years ago
@aphyr thanks for your interesting questions - I am not the maintainer, so don't have answers for you. I would emphasize that libchan is pretty early and rough. @shykes has been travelling but hopefully he can respond with some detail here.
Hi @aphyr, libchan relies on the underlying transport to guarantee ordering (either SOCK_STREAM unix sockets, spdy/tls sessions or actual golang channels). When the underlying connection/session/channel is closed, that must result in the libchan channels closing as well. Then it's up to the application to re-open.
In short: there is no magic here.
Cool cool. Might want to document that these don't have the delivery semantics of Go channels, then. :)
Sure. We welcome pull requests :)
On Monday, June 16, 2014, Kyle Kingsbury notifications@github.com wrote:
Cool cool. Might want to document that these don't have the delivery semantics of Go channels, then. :)
— Reply to this email directly or view it on GitHub https://github.com/docker/libchan/issues/22#issuecomment-46201311.
Triage this can be closed - @aphyr I think you should be able to do this, or @shykes
Closed by #26
The readme says:
And the Golang spec, regarding asynchronous channels, says:
How does libchan enforce the ordering/delivery properties of golang channels when the underlying transport is disrupted--e.g., when re-establishing a TCP link that dropped, how does the channel state machine negotiate redelivery of incomplete in-flight messages? Do libchan channels yield at-least-once delivery? At-most-once? Exactly once? Are there any ordering invariants, or can messages be arbitrarily reordered? If ordering is preserved, what are the space costs on both sides of the network?