Finish up Addon sending, hook up to Obsidian web services

[Zidane]

With the launch of obsidianbox.org, we have the XenForo ResourceManager that backs the Addon "Store" with XenAPI by contex. Obsidian, on the client, will be pulling down addons from the store to increase the security of the content being received.

The process works as follows:

• Client joins server, Server asks Client for list of addons and their MD5s
• Client responds with this list.
• Server checks this list against its own.
• Server sends Client list of addons to download from Obsidian web services along with MD5 of Server addon for any missing on Client.
• Client uses REST to connect to web services and check if the store has an addon with the identifier and MD5 the server gave it. If Client cannot find one, it leaves Server.
• Once Client is done downloading, it sends its new list of addons with MD5s to the server. Server responds with list of addons Client should initialize.
• Client initializes its addons
• Game continues

phew Sounds like a lot but really isn't. This is the production mode for the framework. I do want to support servers sending "untrusted" addons (if client has that option enabled) but needs some thought.

[Lunaphied]

Untrusted addons only work not based just on a config option, but based on a manual I accept when joining the server (more to help server liability for issues if needed). Also an ability to get a list of addons from the server prior to connecting, like using the addons button on the main menu to checkout the addons list per server and having the server tell you what it's running would be good.

[Lunaphied]

I have found a way to get the addon's over to the client. On client side only, as part of the handshaking, but before the handshake happens a FMLNetworkEvent.CustomPacketRegistrationEvent occurs. The operation field of the event is always REGISTER. This only happens when a client connects to a Singleplayer or Multiplayer server. So if we can get the server to send the AddonList message as normal by triggering it from the client, we can have the addon's registered before the handshake fails.

[Zidane]

That could work.

How do you propose suspending the client until we have all addons downloaded and enabled?

[Lunaphied]

We could use some gasp blocking network IO. Or we could hope that it will sit there long enough on it's own. I'm doing some digging to see if I can use it as a way to jerry rig the handshake stuff, but I doubt I'll get it to work. So I think blocking network IO is the answer, server side we can use netty, but client side we will have to use a blocking system to force it to wait until we're ready, or we could have a infinite loop because I think netty is all on threads and just wait for netty to finish. Then we would register the addon's and load them.

[Lunaphied]

http://stackoverflow.com/questions/8467709/netty-with-blocking-io-clients-browsers

[Lunaphied]

Looking into it further, I can't seem to use the forge network channels yet at that point. Working from the client side to make this work is going to be a lot more challenging than working from the server's perspective.