Comments (5)
Also: backpressure semantics.
from libchan.
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).
from libchan.
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.
from libchan.
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..
from libchan.
@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.
from libchan.
Related Issues (20)
- undefined: spdy.NewClientTransport HOT 1
- How to migrate code from v.0.1.0 version ? HOT 2
- how to set timeout when send a message? HOT 1
- Add example using websockets HOT 1
- WebRTC data channel support HOT 7
- Enable Sourcegraph
- pub/sub broker implementation HOT 2
- Calling Send() with large objects errors out in the spdy implementation
- Prosposal: enhanced logging and debugging HOT 2
- it's *not* 'Like Go channels over the network' HOT 9
- handling many request types HOT 18
- libchan.Pipe and spdy.Pipe have different return value order HOT 1
- Add channel select capability HOT 3
- Anonymous embedded structs aren't supported HOT 2
- HTTP/2 transport HOT 5
- SSH stream provider implementation
- Go chan encode/decode
- Support CBOR
- Add synchronous and buffered send channels
- Use Go channels with libchan.Pipe HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libchan.