[Enhancement]: Protocols need to send additional packets after the RMC response

[ashquarky]

Checked Existing

• I have checked the repository for duplicate issues.

What enhancement would you like to see?

Various protocols generate additional traffic outside the basic RMC request-response model, but nex-protocols-go does not provide enough control over ordering to implement this fully.

For example, take matchmaking and its participation notifications:

(Capture from Minecraft: Wii U Edition on Nintendo Network)

Note how the RMC Success response is delivered first, then the notification events relevant to the joined match. The PRUDP sequence numbers also reflect this ordering.

Under the current design of nex-protocols-go, this isn't possible to emulate, since the protocol implementation only gets to return a single RMC response, and globals.Respond will only ever emit a single PRUDP packet.

nex-protocols-go/matchmake-extension/join_matchmake_session_with_param.go

Lines 40 to 46 in a9e527b

	rmcMessage, rmcError := protocol.JoinMatchmakeSessionWithParam(nil, packet, callID, joinMatchmakeSessionParam)
	if rmcError != nil {
	globals.RespondError(packet, ProtocolID, rmcError)
	return
	}
	globals.Respond(packet, rmcMessage)

Currently this is worked around by emitting the notifications inside the protocol implementation itself, but this results in the wrong ordering.

Any other details to share? (OPTIONAL)

Some ideas for improving this:

1. Add an events system, like the existing emit("data") stuff in nex-go, to either PacketInterface or a new "call context" struct containing PacketInterface, then add an OnAfterResponse event. The protocol implementation could then register a lambda function to finish up any additional work it wants to do after the RMC response is sent (like notification delivery). This feels like a neat solution since all notification delivery can be handled together after matchmaking is "done".
2. Allow multiple packets to be returned from the protocol implementation, which are then all sent by nex-protocols-go. This is a slightly messier solution for notifications in particular since, in addition to the notifications to the caller described here, there's also notifications going to other unrelated clients too which would need separate handling. Would allow for bundling with the RMC response, though.

[jonbarrow]

Your proposals sound logical to me

1. Having an event system like you suggested is already somewhat being used in the common protocols lib, allowing for some RMC methods to have "OnAfter" callbacks. This is not as powerful as you'd like (can only set one callback, can only access it after a method is called and not before, etc.) but the idea is being used to some degree https://github.com/PretendoNetwork/nex-protocols-common-go/blob/db917c2172e7443ff01a7f162223ab3df5f1fc5d/ticket-granting/protocol.go#L21-L23
2. Contexts can possibly be a good fit. We would need to explore this more though. Using contexts is something I've been thinking about as well. Not only do the official clients use call contexts, but also contexts are a core part of Go programs like this. That being said, we would need to be careful. Contexts in Go are MOSTLY used for things like signal sharing, which really boils down to things like timeouts and cancellations. However Go contexts ARE also intended to be used for passing request-scoped data between functions, which is our exact use case. Go provides a WithValue method for creating contexts with attached values, and WithValue calls CAN be chained such that we can store multiple values per context. But it's not usually recommended to abuse this and treat it like a mini key-store, and it adds some extra boilerplate for accessing since we lose type information. It also creates a copy of the data, rather than linking directly to existing data, which may not be ideal. We can always create our own context type (like how we created our own primitives and error types), but the official Go stance is to not do so: Don’t create custom Context types or use interfaces other than Context in function signatures. (though people still do, it just usually gets a bad rep). Some extra info on Go contexts, they are definitely super useful and we should probably explore their use cases for us (such as passing RMC details, allowing for an RMC handler to trigger a signal like a cancellation or timeout, etc.):
   • https://pkg.go.dev/context
   • https://www.reddit.com/r/golang/comments/18mphqt/what_even_is_context/
   • https://www.reddit.com/r/golang/comments/1gn5e2c/what_is_context_in_golang/
   • https://www.reddit.com/r/golang/comments/qpeh6f/explanation_of_context_in_go/
   • https://www.reddit.com/r/golang/comments/y2voom/what_are_the_use_cases_for_contexts/
   • https://www.reddit.com/r/golang/comments/wwsclz/trying_to_understand_context_better_specifically/
   • https://www.reddit.com/r/golang/comments/19e9i76/for_custom_contextcontext_should_i_composite/
   • https://www.reddit.com/r/golang/comments/fo395d/how_do_you_use_contextcontext_in_your_applications/
   • https://www.reddit.com/r/golang/comments/q17xr2/why_not_custom_context_type/
3. Honestly returning multiple RMC messages is not a horrible idea. It would conflict a bit with [Enhancement]: Add RMC protocol details to response packets automatically in handlers #93, but is nothing that can't be worked around. I definitely don't hate the idea of "just return a list of messages, let the protocols lib loop over them to resend them"

CC @DaniElectra for thoughts on this