Network Resource Manager interface #229
Conversation
| // TransactionalScope is a mixin interface for transactional scopes. | ||
| type TransactionalScope interface { | ||
| // Done ends the transaction scope and releases associated resources. | ||
| Done() |
There was a problem hiding this comment.
Do we have any examples of how we think we might want to use these interfaces? We should start with some toy applications before we spend too much time on these APIs.
There was a problem hiding this comment.
The most basic hooks will be inside the transport and muxer implementations.
We need to cater to both them, at the bowels of the stack, and higher level users.
There was a problem hiding this comment.
Can we add testable examples to the godocs? https://go.dev/blog/examples
The stream is unnegotiated state until the actual protocol has been determined.
1. Introduce transactions in all scopes 2. Limit the view of stream/connection scope for users, to avoid the Done footgun 3. Move OpenStream to the resource manager
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
…mory status so that we don't have to undo reservations if there is too much pressure.
It needs to attach the protocol to the protocol scope, which may fail.
marten-seemann
force-pushed
the
feat/rcmgr
branch
from
3042c2a
to
0391e67
Compare
Co-authored-by: raulk <raul@protocol.ai>
Co-authored-by: raulk <raul@protocol.ai>
Co-authored-by: raulk <raul@protocol.ai>
| ViewTransient(func(ResourceScope) error) error | ||
|
|
||
| // ViewService retrieves a service-specific scope. | ||
| ViewService(string, func(ServiceScope) error) error |
There was a problem hiding this comment.
Does service deal with transient connections too? How does hole punching figure into this (e.g. when secondary connections associated with the service are made)?
There was a problem hiding this comment.
No, the service does not deal with conns at all, it only deals with streams.
Conns are really shared resources, so there isn't much of a point to have them owned by a service.
network/rcmgr.go
Outdated
| Stat() ScopeStat | ||
|
|
||
| // BeginTransaction creates a new transactional scope rooted at this scope | ||
| BeginTransaction() (TransactionalScope, error) |
There was a problem hiding this comment.
Under what kinds of situations are we expecting an error here? Is this just room for growth in case anything comes up, or do we have some in mind?
There was a problem hiding this comment.
We currently error if the scope has been closed. But it's good to have room for growth too.
| NumStreamsInbound int | ||
| NumStreamsOutbound int | ||
| NumConnsInbound int | ||
| NumConnsOutbound int |
There was a problem hiding this comment.
How (if at all) are we planning to deal with these in the context of relayed or DCUtR connections?
There was a problem hiding this comment.
what do you mean here? Relayed connections are just a virtual connection on top of some other connection and don't use fds.
There was a problem hiding this comment.
We do count them however in stat.
Co-authored-by: Adin Schmahmann <adin.schmahmann@gmail.com>
|
|
See libp2p/go-libp2p#1260 for the proposal/design discussion.