Server Age Mod Ideas

[jrddunbr]

This mod should be relatively simple from the user's perspective:

• Server Rack - can hold 4 rack units of equipment and handles various inter-connectivity; strictly A-B type stuff, no switching/routing
• 1u Network Switch - controls networking in a rack
• 1u Server - a simple server
• 2u Server - a more powerful server
• Workstation - a server as a standalone block (same size as a 2u)
• Serial Console - a tool that lets you get a serial console on a server
• Conduit - Provides fiber and Ethernet a place to run between workstations and/or racks.

Blocks:

• Server Rack
• Workstation
• Conduit

Items:

• 1u Switches (rackable)
  • 3 Ethernet + 4 Ethernet Uplink Variant
  • 3 Ethernet + 2 Fiber Uplink + 2 Ethernet Uplink Variant
  • 3 Fiber + 4 Fiber Uplink Variant
• 1u Server (rackable)
• 2u Server (rackable)
• Serial Console #10
• Ethernet Cable (limited to 32 blocks, limited bandwidth)
• Fiber Line

Crafting Items.. these may come from Processing Age or other Age-mods.

• Motherboard and CPU - there will be different kinds
  • x86 container
  • x86 VM
  • x86 EC2 (whatever works - user will have to provide IAM role from template for permissions
  • x86/Arm Lambda - user will have to provide IAM role from template for permissions
  • These are crafted independently but due to various limitations of VPC's, the EC2/Lambda systems will only have very specific networking capabilities and supported cards will be more limited than containers or VM's.
• Ethernet Card
• Fiber Card (1x, 2x variants)
• SFP's
• Ram #12
• Disk - This will depend on the system but probably start from a container image of sorts (except Lambda)
• Disk Controller Card - This makes it so that you can access more than 2 drives
• Internet Card - Allows communication to the public internet (think NAT)
• Unlimited Internet Card - Allows opening listening ports to the local network on top of capabilities of Internet Card

Mechanics

The rack will have 5 sides. Each side can be connected to a different conduit. Conduits can have junctions.

In order to use a conduit, you must configure the connection using an Ethernet Cable or Fiber Cable, which will create a link between two endpoints that the Conduit is aware of. You can right-click any portion of conduit with a cable to open this interface. Ethernet cables are limited to 32 blocks of conduit length.

Racks have names as configured in their GUI (the same one used for configuring the devices within) that shows up in the connected Conduit networks.

Conduits can carry .. a few cables (8?). They are colored using Minecraft colors.

When you bring up the rack config, you can configure the servers and network switches with their connectivity with the 5 connectable sides of the block (the front face is not connectable). This allows you to do basic drag-drop connections between incoming conduits and the various slots.

Additionally, on the other side of the rack slots, you can connect the various servers in the rack into the network switch(es) of the rack. This uses a similar drag-drop interface and requires one cable item per connection.

Depending on the cards installed, servers can have 1 to 4 connections on them. Most 1u servers can have 1 card and a built-in Ethernet, most 2u servers can have 4 cards and built-in Ethernet. The reason it depends is because Lambdas and EC2 instances will be handled differently due to various limitations.

I do want to have various limits that bring these computers down a notch on processing power, namely slow networking (slower still with Ethernet as opposed to the Fiber), slow CPU cores (but multiple in the 2u boxes) and other design decisions.

I also want to make sure that boxes are locked down with a permissions system to the player using them; particularly for the AWS systems since people are going to bring their own accounts for that which integrates with the server via the AWS API direct from the Minecraft server. This will be configurable in the mod but we do need to be careful to only allow this for online mode Minecraft servers, as offline mode ones don't restrict players from impersonating one another.

The serial console will literally give the user a serial console. It's the most basic interface; we will not provide any framebuffer/keyboard/mouse support. Basically, the serial terminal allows you to configure it enough to do basic things, and if you need more power, get an Internet card or use SSH.

Somehow, we will allow disks to be moved from system to system so that you can set up Lambda boxes without directly typing the code into the serial terminal for the lambda, although we will provide a basic LambdaOS for this interface so that you can type your code and provide your inputs.

I think that the Lambda component would be really cool (particularly since it's cheap compared to EC2 for what we're probably doing) but it might have some interesting implementation challenges. Values passed back and forth between the Lambda and the mod will probably need to have some standardized format so that we can share 1) game state to the Lambda based on the inserted cards and messages and 2) let the Lambda inform game state back to the game server.

[BomberPlayz]

If we will have USB thumb drives, we also should have USB cables and hubs?

[jrddunbr]

No. The purpose of them is to have media that can be moved from system to system. Odds are the way this will be handled is that the item is consumed into an internal inventory while in use.

USB cables and hubs are not exactly part of this since we don't really need to have hubs; you will just run out of slots.

We mention the USB technology in the issue mostly because this is how we're going to expose it to Linux inside the VM that we use; the actual Minecraft name will just be "flash drive" and not expose that it's using USB for this. It can store random data or it can be an entire bootable image; the former will probably only support much smaller filesystems of like 16 megabytes, the latter will have to support probably larger than 1GB in order to fit Arch Linux or whatever we're shoving in our VM's.

Containers won't have this option since the containers will just boot Alpine or something, and any AWS resources won't really apply because they can't boot an OS from the flash drive; you have to install them with the correct OS from the start by cloning an AMI. Lambdas don't apply here either, however we may expose the filesystem so that Lambda can actually query what the files are in case that's a use case for your device.

Obviously this is totally WIP and we don't really have much of this set in stone except that we might want to do it and how we would go about it.

[BomberPlayz]

It would had been cool that you would have to plug keyboards and mouses into, like IRL.

[jrddunbr]

We're going to allow the user to plug in a serial console. It's an item that you hold that you can "connect" to the device to set it up.
Mouse doesn't really make sense since it won't really have a "screen" per-se. At least, not initially, and probably not as a framebuffer but as some form of screen connected over GPIO.