Expanding node "width" Options

[reemul]

Here's something I was toying with in my head. See if it makes sense to you folks.
*****

SR 4 has abstracted the idea of a node to be independent of the physical architecture of the devices involved. A node could be one commlink, one area, or some virtual construct on the matrix. But the attributes for the node are still written as if it represents one single commlink or equivalent. You can increase the Response to make the node faster or boost the System to take advantage of higher Response and support more programs and subscribers, but you can't scale the changes to reflect a busy node that actually was used for real work by multiple users. For example, you can't, under the existing rules, ever have more than 12 active subscribers. That's great for your personal devices, a mom and pop business, or a designed security bottleneck, but it wouldn't even work for the accounting department at a mid-size corp office. You're stuck adding nodes instead of expanding the capacity of the virtualized one you have, and you end up back with a SR3 dungeon crawl between nodes to find anything.

So, we increase the node's "Width". Shorthand for the old-style bandwidth, nodes with increased Width are commonly called wide or fat nodes. The rating could represent anything from an upgrade to a single device, additional devices slaved together, or even fractional capacity leased from somewhere else on the Matrix. Each increase in width acts as a multiplier to the maximum number of subscribers allowed and likewise increases the number of programs that can run without reducing Response. Nodes can have (System x Width) x 2 subscribers, and Response decreases for every (System x Width) programs running. By default all existing systems have Width 1. Each additional rating point costs the same as a Response increase at the existing Response rating of the node. Increasing Width of a node with Response 3 would then cost 1250:nuyen: per point, Response 4 costs 2000:nuyen: and so on. Buying Width at a different Response value causes the node to operate at the lowest of the available Response ratings. Increases to Width can be bought separately and incrementally, it isn't necessary to buy an entire new system with the desired rating.

Multiple devices running the same System can be combined into one virtual node with a Width equal to the sum of the ratings of the devices used and a Response equal to the lowest rating involved. Adding devices to the virtual node requires Administrator access to both the node and the new device, and a System Reset of the new device. The loss of a device from an existing node merely decreases Width, the operating system automatically compensates for the loss of capability although the number of programs still running may now cause a decrease in Response.

A small company wanting to be able to run 8 programs at rating 3 on their node would find it cheaper to buy Response, Width, and System at 3 each than to buy Response 5, Width 1, System 4 under the RAW. (Which would then run at Response 3 due to the number of programs running.) 1250:nuyen: x 3 for Response and Width + 600:nuyen: for System = 4350:nuyen: vs 4000:nuyen: for Response and 2000:nuyen: for System = 6000:nuyen:. Upgrading the RAW 5/4 system further to support more users and programs would require increasing System to 5 for 2500:nuyen: or even bumping Response to 6 for 8000:nuyen:. The wide node only has to add more width at 1250:nuyen: a point.

Increased Width does not take up additional physical space (within reason). A commlink should easily be able to handle Width 3. Perhaps some capacity rating for the physical devices should be used to keep this reasonable (no Width 6 implanted commlinks running enough Agents for a baseball team). Yes, this means that experienced runners will have their gear running fast and fat, but it also means that there can be program space for extra IC on almost anything they face.

[hobgoblin]

hey, nice. strange that noone have commented on this one :)

in many ways its similar to how sites like slashdot is managed. they have a backend database and a front end load balancing computer, and several inbetween webservers that have as a single task to manage dynamic content out to the individual users.

i was also thinking of a similar system for managing agents running on a corp node. each device that makes up the node would have a response rating and system rating equal to the overall ratings of the node. but when its comes to load balancing, the agents especially are spread across the different nodes. that way you can in theory run more agents then a single device can manage, but as all the devices share a nodes "address-space" they can all interact with every other device as if it was a single, large, device.

hmm, would be interesting to pitch all this at knasser :)

[Starmage21]

[hobgoblin]

yep, its know as the agent swarm. and its been debated ad infinitum on this board since the release of SR4.

but to cut of the rampaging dragon before it gets up to steam, if one keep the idea of the node and the idea of the persona separate, it solves the agent swarm nicely imo. at least for the issue of a hacker bringing a near infinite number of agents with him to attack a node.

[mfb]

this subject has definitely come up before, just not in this manner. the Agent Smith problem is directly related to this issue. i'm pretty sure Unwired is going to have rules addressing this issue.

[knasser]

[hobgoblin]

true that. the way i have found to interpet subscription recently, is the number of places you can have your persona active, not the number of data connections a node can maintain. thats why im talking about keeping the persona seperate from the node.

as in, while a corp node can do this load balancing trick. said setup would preclude the ability to maintain a persona for a single user. therefor you cant pull a agent smith scenario as that either max out at your personas ability to handle connections, or the response and system of the node maintaining your persona for when you attempt at loading the agents into said persona (as i understand it, the agent must then be running as a program on your home node).

or to sum it up, if the agent isnt part of your persona, it will have to hack its way in on its own, and you can only command (response x 2) - 1 of those at any one time (unless your doing a whole lot of task switching or grouping them, see drone groups).

if it is part of your persona, then it needs to run as a program on your comlink or similar node creating device.

then its a simple matter of not allowing a cluster node to generate or maintain a persona for any single person jacked directly into the cluster. as in, you will need a "terminal".