Orion Framework: Internal Message Queue

[Ijwu]

Event handling, in its current form, relies heavily on the C# event object. This is seriously limited in that services may not define prioritization or handling order.

An internal message queue would allow for all services to write events to the queue and allow all other services to receive and respond to messages in a pub-sub pattern.

[Ijwu]

[bartico6]

Essentially the problem is that currently only the networking classes are publishers, which means that plugins that emulate any sort of behavior that would normally come from networking classes are essentially unfeasible as you have to hack your way into the networking (if even possible) rather than simply fire an event.

I think the way Bukkit works, a similar solution to which is being proposed here, (you subscribe to events (that can come from networking or from other plugins) rather than hook networking) is good because it both enables serverside emulation and allows plugins to easily communicate between each other (a plugin can fire CustomPlayerAbilityEvent and have another addon handle it and grant buffs or currency for it). 😄

[tylerjwatson]

My original design of Orion handled this kind of thing, but not in any specific form. In my designs, I simply used the .NET event mechanism for attaching delegates onto event handlers.

I suppose it depends on what you mean by limited. Events are limited in and of themselves, but I suppose I am asking what is the actual problem we are trying to solve here?

• Handler priority is limited, but is as designed: Who decides handler priority? Is it configurable, and by what? Any elasticity here means additional complexity; event handlers really should be ephemeral, in that they shouldn't care about anything else in the chain apart from what they are supposed to. Anything else, in my experience, (I've done this incorrectly in production in the past) means we're going to have a maintenance nightmare of co-dependent event handlers requiring the chain to be instantiated in a specific order - and in that case, you've lost any flexibility you set out to give developers in the first place.
• What specific network-related hooking are we talking about here? Something that can't be worked around in a high level library?
• In Orion, we really should provide services that completely abstract the inner workings of Terraria away from plugin developers, who really shouldn't care too much about how it actually works, only that they can call some functions and it does stuff. If you need to add hooks that send packets and do a bunch of low-level things, we've failed as an API library; perhaps we can look at the use cases and develop services around them?

Cheers, T.

[bartico6]

• priority is determined by plugins when registering. They register an event with chosen priority. Loggers would set the event priority to MONITOR to have the event after everyone, region protection or anticheat would want to be at the top of the food chain etc
• if all plugins use netgetdata to protect tiles, how do you consult tile access with other plugins?
• thats why, to avoid net hooking altogether I am arguing for events that can be produced by anything, by default the networking engine. Events are easier and more intuitive than net hooks.

[Ijwu]

Question for you @tylerjwatson: If a plugin needs to revert or cancel and event, how does it go around doing that without causing issues for others? From what I've seen, it's a legitimate use case for a plugin, such as region protection, to throw out an event with intent to ignore it. If it doesn't handle it first then another, less important or critical, plugin could break the chain first causing a security issue.

[QuiCM]

With that being said, 'handling' an event does not currently break the chain. The onus falls upon other plugins to check the handled state of the event which is, in my opinion, unintuitive

[tylerjwatson]

The onus falls upon other plugins to check the handled state of the event which is, in my opinion, unintuitive

Agreed, I think we can improve that design a lot by checking the flag at each stage.

[bartico6]

If tShock had its handlers running before plugins (due to, say, registering with a higher priority) then plugins should have a way to 'un-cancel' the event, same goes for other plugins' actions being "reversed" by another plugin further down the chain. Here is a viable example, yet again, from Bukkit:

This event can be marked as disallowed before the first plugin sees it (by the server) - this is good because it allows to (rather than stop the server from doing anything completely) override only certain actions made by it. In this case, if the stock server thought the server is full (the plugin has its own max-players override) but my plugin didn't - the event would be reset to the stock, "allowed" state.

As a compromise, plugins that don't plan to do hardcore event reversing stuff should have a flag when registering their event - "no-cancelled-events" which would not send any events that are marked as handled to their callbacks.

[kevzhao2]

In the reboot branch, I now have a HookHandlerCollection<TArgs> class which should handle this properly. You can annotate hook handlers with priorities, and the class is immutable and hence thread-safe.

[kevzhao2]

Closing as these concerns will no longer be relevant due to the new event API.