Flow control
Technical Discussion
10
Posts
6
Posters
10
Views
-
I've been thinking lately about flow control. That's a feature of some networks where a receiver can tell a sender to slow down its sending rate to match the receiver's processing rate.
In TCP flow control, the receiving host returns a receiving buffer size in its acknowledgement segment, so the sending host know how much data it can send without overflowing the buffer.
I wonder if there are ways that a receiving ActivityPub protocol server could tell the sending server to slow down? Maybe we could reuse some of the RateLimit headers.
Another option would be a special header that says how big your incoming activity queue is. "I have a very long processing queue right now, please keep stuff in your outgoing queue for a while."
-
Obviously the other option is to keep sending until the receiving server fails, and then do exponential backoff until the remote server can process your activity again.
But I'm looking for something more adaptive that adjusts the sending rate before the receiver fails.
-
fentiger@mastodon.social yes, but by that point you've failed. What I want is to have more adaptive sending, so you don't get to the 429 code.
-
@evan No, you haven't. You just need to back off and retry, just as you do for an ACK timeout in TCP.
-
fentiger@mastodon.social yes I was also thinking of the venerable 429.
evan the thing is, both approaches rely on the receiving end to support it. I would make the argument that a 429 would have nominal support from some implementations, but then again I wouldn't actually bet money on it.
Either way you're looking at an FEP to establish flow control signalling or 429 handling. I'd then make the argument that putting together guidance for 429 (+ exponential back off) is easier than specifying flow control logic.
-
@evan does AP have a way to send control messages, just meant for the receiving server?
-
Currently whenever a POST is sent to an inbox the response body is ignored. The http status code is checked for errors but that's it. Perhaps some more complex information about the state of the receiving ingress queue could be conveyed in the body.
-
@evan No, you haven't. You just need to back off and retry, just as you do for an ACK timeout in TCP.
fentiger@mastodon.social Flow control is the feature in TCP where the receiving host, in its ACK, can send back information about its remaining buffer space. The sending host can slow down its sending rate to prevent overflowing that buffer. If this works correctly, no error is ever sent.
-
@evan
HTTP 420/CHILL OUT?Actually I do see HTTP 429 TOO MANY REQUESTS, which seems exactly what we want. I don't know what support is like though, I've not seen explicit support for it in the few bits of AP Federation code I've taken apart.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Yeah I went the SSE route too. Nice n simple.
-
@evan this is what happens when you read the fedi at stoplights.
I'd think some kind of link to the "triggering" activity in the result.
(I'm speaking from a very old and rusty memory of AP, but)
Is a result an activity? Can it live on it's own? If not, it seems like a processor can make the assumption that object → result? Otherwise, a link to the triggering activity by id could work. But what to call that link? <shrugs>
-
sivy@hachyderm.io I used an example in my original post! The result property describes this relationship.
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-result
Here are a few more:
When an actor arrives at a place, the actor updates their own location When an actor likes an object, the actor adds the object to their liked collection When an actor unfollows someone, the actor removes that someone from their following collectionSo, I see it particularly useful for the side-effects defined by ActivityPub, but there may be other good uses.
-
@evan I don’t know just random driving thoughts
-
@evan@activitypub.space @evan@cosocial.ca i.e. can another activity be considered a cause which raises the question of whether an activity stream stream can be considered a network graph delivered overtime
-
@evan hi Evan, I think we would need some examples of what you consider a cause to be in order to develop this idea further
-
fentiger@mastodon.social Thanks, I'll look through it for ideas.
-
evan makes a ton of sense! The ActivityPub API doesn't have a subscribe mechanism, so this makes sense.
SSE also makes sense vs web sockets. There are plans on our end to establish SSE as well, and deprecate our own websocket implementation.
