Context-Scoped Sessions

[Stebalien]

Currently, bitswap sessions are hard to work with because we need to:

1. Create a new session.
2. Pass this session to all services that need access to the exchange.

Usually 2 involves re-creating these services. This can be very painful and we have many places in go-ipfs where we simply aren't doing this.

Instead, we should associate a session with a context. That way, whenever we use the context, we use the session. When we cancel the context, we cancel the session.

PRs

• switch to storing sessions in the context go-ipfs-exchange-interface#9
• Context-based sessions go-bitswap#401
• feat: use new exchange session logic go-merkledag#55
• feat: use the context to thread sessions through all commands #7201

Design

Store a session "key" in the session to identify the session.

// SessionID is an opaque type uniquely identifying a session.
type SessionID struct {
	// Opaque type to ensure users don't cook this up and break things.
    // Sequentially and atomically allocated.
	id uint64
}

// IsZero returns true if this SessionId is the zero value (not a valid session
// ID).
func (id SessionID) IsZero() bool {
	return id.id == 0
}

// NewSession registers a new session with the context. The session will be
// closed when the passed-in context is canceled.
//
// If there's already a session associated with the context, the existing
// session will be used.
//
// This function does not initialize any state, it just reserves a new SessionID
// associates it with the context.
func NewSession(ctx context.Context) context.Context {
  ...
}

// GetOrCreateSession loads the session from the context, or creates one if
// there is no associated session.
//
// This function also returns the context used to create the session. The
// session should be stopped when this context is canceled.
func GetOrCreateSession(ctx context.Context) (SessionID, context.Context) {
  ...
}

Alternatives

I've considered two alternatives:

1. Store the exchange/fetcher in the context.
2. Store an abstract session in the context.

Embedded Exchange

We could:

1. Create a session.
2. Store the session/"fetcher" in the context.
3. Use this session inside the blockservice instead of the actual exchange.

On one hand, this is nice because we can embed alternative exchanges for a specific request. For example, we could embed an offline exchange to perform an offline lookup.

On the other hand:

1. This is spooky action at a distance.
2. This only solves this particular problem and doesn't help services exchange information related to sessions.

Abstract Session

We could also store an abstract session object in the context (#6525). However, this would require building a general-purpose, abstract session/state manager. The session-key design lets us do everything the abstract session proposal does, without requiring a general-purpose anything.

[hannahhoward]

so I gave it a glance over — generally, yes, thumbs up, good plan, seems much closer the web apps uses cookies (which store minimal data, but can be used to lookup other session information). one thing that isn’t totally clear to me: is the code you’ve written out supposed to go in go-bitswap or go-ipfs? If go-bitswap, I wouldn’t want to disable the ability to make sessions manually for some other use case besides go-ipfs (for example, filecoin, which may still use bitswap sessions for blocksync in Lotus? -- not sure there)

[Stebalien]

In go-bitswap. I'll leave the NewSession function there as we explore this interface. However, if the context contains a session-key, NewSession will just return the session associated with the key.

[Stebalien]

I had to change the design slightly to use integer IDs:

1. *struct{} isn't guaranteed to be unique.
2. I wanted a nice stable string representation. However, *anything can move.

So now I'm just atomically allocating increasing 64bit IDs.