Comments (11)
or is it different since one side assumed that its peer had a higher limit, even if that limit was never explicitly set?
Yup, exactly.
If that solution sounds good I'll try to implement it some time soon.
from ilp-protocol-stream.
What if 'connection'
just didn't emit until the rate/destinationAccount
are both ready?
from ilp-protocol-stream.
The main issue I see is that we do kind of want the receiveMax
to be set before the connection responds to the first packet so that we can get to sending the actual money ASAP. I'm not sure we want to wait for the full handshake before starting with real packets.
from ilp-protocol-stream.
I see what you mean (and this may be a separate issue), but I don't really like the asymmetry in the API of: the client doesn't get the use a connection until the rate is available, whereas the server gets it immediately.
Is the receiveMax
usually getting to the same value for every stream? If so, there could be a default value in ConnectionOpts
.
from ilp-protocol-stream.
We could set the receiveMax
to Infinity
by default, but it could be a bit strange if money just starts showing up. We could also do that plus add a field to the connection/server options that allows you to set the default receiveMax
for all connections, so you can ensure you don't get money out of the blue if you don't want it.
from ilp-protocol-stream.
That sounds reasonable. Its also has the benefit of being extremely similar to how data offsets are handled.
If a connection/stream is initially configured with receiveMax=Infinity
would it be allowed to decrease it later?
from ilp-protocol-stream.
Ah, good point -- that was another reason we didn't set it higher later. If we follow the QUIC model, it isn't possible to lower the limits. Because you don't know what order packets were sent in, they assume that you only ever raise the limits and can discard anything that's lower.
One option might be to:
a) start at Infinity, but don't send a frame over the wire
b) assume the other side is at Infinity until you're told otherwise
c) once you set a limit, ignore frames that lower it
from ilp-protocol-stream.
Right now the connection allows the data offset to be decreased in some cases -- is that a bug? (
ilp-protocol-stream/src/connection.ts
Lines 634 to 635 in afd51ba
I can't find any issues with your proposed solution -- if some race occurs and one side does oversend, they'd just get a ILP reject packet with a StreamMaxMoney frame which seems like the right behavior.
from ilp-protocol-stream.
That solution sounds good.
Re: the data offsets, it is a bit different from money -- if one side sends too much data it's a flow control error and the connection is terminated, as opposed to money which just rejects the packet.
from ilp-protocol-stream.
@emschwartz thinking about this some more, won't this be a breaking change? The current implementation of stream is expecting a MaxMoneyFrame, and if it doesn't get one from the new version of stream it will assume a RemoteReceiveMax of 0, which is blocked.
from ilp-protocol-stream.
Good point. Sounds like we can only do two of these three things:
- Change the default
receiveMax
from0
toInfinity
- Disallow decreasing the
receiveMax
- Be compatible with the existing implementation
Need to think about this a bit more, but this is definitely the kind of assumption that should be made explicit in the spec.
from ilp-protocol-stream.
Related Issues (20)
- receiveTotal resolves before fulfillment is sent HOT 1
- Unable to establish connection, no packets meeting the minimum exchange precision of 3 digits made it through the path. HOT 1
- Probing/exchange rates are not a STREAM concern HOT 10
- An in-range update of @types/chai-as-promised is breaking the build 🚨 HOT 1
- Update connection.totalDelivered before outgoing_money
- Unique id per money event HOT 10
- Send-only mode HOT 5
- Stateless STREAM Server
- An in-range update of @types/webpack is breaking the build 🚨 HOT 7
- verifyReceipt function signature
- Connection Timeout HOT 1
- Inactivity Timeout HOT 1
- Connection Timeout HOT 1
- An in-range update of ilp-logger is breaking the build 🚨 HOT 6
- An in-range update of @types/node is breaking the build 🚨 HOT 29
- An in-range update of oer-utils is breaking the build 🚨 HOT 4
- Don't serialize JSON for logging unless debug is on HOT 1
- An in-range update of @types/sinon is breaking the build 🚨 HOT 2
- Try compiling using Assemblyscript? HOT 2
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 ilp-protocol-stream.