Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Secure Component Switch (Indepth Explanation Within) #1277

Closed
MyNameIsKodos opened this issue Jul 8, 2015 · 19 comments
Closed

Comments

@MyNameIsKodos
Copy link
Contributor

Alright, here goes my best attempt to explain this as clearly as I can.

The Secure Component Switch would have one sided 'input', and five sided 'output's. This would enable entire sections of components to be independently added and removed, allowing for everything from being able to have more than the normal limit of components added to a computer (via being able to 'shut off' certain sections of the network), to being able to have things like password protected Raids, etc.

Here is an example screenshot of its usage.

Example Screen 1/?

In the above screenshot, let's pretend that the two pieces of wool are both Secure Component Switches (Hereafter referred to as SCS). In the green one, a method has been called to enable a computer attached on the lefthand side to reach the second SCS on the right. However, in the righthand SCS, the method to disable the right-side facing of the SCS thus preventing the computer from accessing any components beyond that point.

Optionally, I'd like to be able to add a 'password' string to the SCS, in the same manner that Zetta Industries does in the RF Meter's methods. If further explanation of that is needed, I can provide links to the ZI Repo, or if @marcin212 would be willing to elaborate he is most welcome to.

If there are any additional questions, drop me a line here or in IRC.

If you've gotten this far, thanks for the time you took to read this, and I hope this is taken into consideration.

@gjgfuj
Copy link

gjgfuj commented Jul 8, 2015

This'd fix #1273 right?

On Wed, 8 Jul 2015 9:26 pm Kodos Atoz notifications@github.com wrote:

Alright, here goes my best attempt to explain this as clearly as I can.

The Secure Component Switch would have one sided 'input', and five sided
'output's. This would enable entire sections of components to be
independently added and removed, allowing for everything from being able to
have more than the normal limit of components added to a computer (via
being able to 'shut off' certain sections of the network), to being able to
have things like password protected Raids, etc.

Here is an example screenshot of its usage.

[image: Example Screen 1/?]
https://camo.githubusercontent.com/aa4fe2c66ad3500b0f10eb40ef18d1a535c4902a/687474703a2f2f6d696368692e70632d6c6f6769782e636f6d2f4d696e6563726166745f312e372e31305f323031352d30372d30385f31352d31352d35352e706e67

In the above screenshot, let's pretend that the two pieces of wool are
both Secure Component Switches (Hereafter referred to as SCS). In the green
one, a method has been called to enable a computer attached on the lefthand
side to reach the second SCS on the right. However, in the righthand SCS,
the method to disable the right-side facing of the SCS thus preventing the
computer from accessing any components beyond that point.

Optionally, I'd like to be able to add a 'password' string to the SCS, in
the same manner that Zetta Industries does in the RF Meter's methods. If
further explanation of that is needed, I can provide links to the ZI Repo,
or if @marcin212 https://github.com/marcin212 would be willing to
elaborate he is most welcome to.

If there are any additional questions, drop me a line here or in IRC.

If you've gotten this far, thanks for the time you took to read this, and
I hope this is taken into consideration.


Reply to this email directly or view it on GitHub
#1277.

@MyNameIsKodos
Copy link
Contributor Author

It's a more advanced version, essentially. I liked the idea, but didn't want just a simple 'hurdur redstone to turn on' cable toggle. I could just about program that in Lua

@gjgfuj
Copy link

gjgfuj commented Jul 8, 2015

Yeah exactly.

On Wed, 8 Jul 2015 9:43 pm Kodos Atoz notifications@github.com wrote:

It's a more advanced version, essentially. I liked the idea, but didn't
want just a simple 'hurdur redstone to turn on' cable toggle. I could just
about program that in Lua


Reply to this email directly or view it on GitHub
#1277 (comment)
.

@Vexatos
Copy link
Contributor

Vexatos commented Jul 9, 2015

@Kodos-Atoz In fact, I did program such a thing in Lua, using a Robot and different dyes to change the cable colour.

@Inari-Whitebear
Copy link
Contributor

Whys there even a component limit <.<

Other than that, interesting idea, don't like the password stuff though, should be done via programs.
Rather than this I think I'd prefer being able to use it as kind of a... demultiplexer?

So that component block has 6 sides. Whichever side is connected to the PC is used for the PC to access it (obviously). With a call of something like setOutput(side) you switch which output side is activated, and it acts like that side is connected to the input side via cable then. (So PC can see everything connected there)
To be able to access something else you'd have to again switch to that side first, and so on. Could use Invalid side to turn it off or so.

@Inari-Whitebear
Copy link
Contributor

At the point of where you would put in an extra block for this you could really just change how the system works though...

Like the machine.lua component thingy has a table of max size 16, which holds addresses, only the component addresses listed there can be used. So to "connect" a new component you'd have to get its address and add it to the table (but maybe you have to throw out another address for that if it is already full). And so on, that way you can switch components. That way the limit also makes a bit more sense (PC has limited address memory for accessing components), and isn't just pulled from thin air.

@MyNameIsKodos
Copy link
Contributor Author

If you hate the limits that much, change them in the config.

This is my own version of a sane solution.

@Inari-Whitebear
Copy link
Contributor

And I prefer a solution that makes the limits make sense, and doesn't add unnecessary blocks :D

@LizzyTrickster
Copy link
Contributor

@Inari-Whitebear if you want to discuss component limits, do so in a separate issue.

@Inari-Whitebear
Copy link
Contributor

@LizzyTrickster I'm not "discussing component limits". Not sure why everyone gets so hung up about that once I mention it once :P

One of the purposes of the suggested block is obviously to be able to switch between sets of components. So you can have a total number of components bigger than the currently active components and turn those on/off as you please.

So I'm pointing out that the same functionality can be achieved by changing the component API and machine.lua a tiny bit. Instead of implementing a whole new block for the same end-goal.

Sure, the 2 things could technically co-exist, but I still don't see a reason to add a new block where it is not needed at all. At the end that is at Sangar's discretion anyway though, I'm just giving my thoughts/feedback. For which issues/suggestions are kind of there too.

And I don't think I should open a new issue for that idea, since it is discussing the purpose of this suggested Block and alternative ways to get that functionality. So at least until this feature is accepted, what I'm saying is, that there would be an (imo) better way than what is proposed. That would be like me telling people who don't 100% agree with my idea for quicker drawing to "get out and make your own issue". Doesn't make sense.

@MyNameIsKodos
Copy link
Contributor Author

The changes to the limits aren't really needed either. 16 is plenty for a normal user, and if you need anything more than that, you should probably be finding ways to implement what you're doing via a server rack, which can support up to 64 components per server anyway. Please stop derailing the topic.

The suggested block is a QoL suggestion more than anything else, but could be useful for securing networks as well.

@Inari-Whitebear
Copy link
Contributor

Well you didn't want to explain to me what other uses your block has, so I have to go by the issue's description.
And well, they'd make the limits better at least, not saying they are "needed".

Past passwording stuff - which can really be done with software - the only use I can see is that you can connect and disconnect subnets. Which as stated (even by you), allows to have a total number of components bigger than the current number of active components.

Not sure what exactly you mean by securing networks ^^

Other than to manage power draw better, it sounds like it would mostly be useful for having a bigger set of technically available components.

So you are saying, that the block is not necessarily required, but would be a QoL thingy that just makes something a bit more user-friendly?

(Off/Meta-topic: I don't regard discussing your suggestion, its merits, and alternatives as derailing a topic about your suggestion?)

@gjgfuj
Copy link

gjgfuj commented Jul 9, 2015

Say you wanted to switch a single screen to display multiple cases?

On Thu, 9 Jul 2015 4:25 pm Inari-Whitebear notifications@github.com wrote:

Well you didn't want to explain to me what other uses your block has, so I
have to go by the issue's description.
And well, they'd make the limits better at least, not saying they are
"needed".

Past passwording stuff - which can really be done with software - the only
use I can see is that you can connect and disconnect subnets. Which as
stated (even by you), allows to have a total number of components bigger
than the current number of active components.

Not sure what exactly you mean by securing networks ^^

Other than to manage power draw better, it sounds like it would mostly be
useful for having a bigger set of technically available components.

So you are saying, that the block is not necessarily required, but would
be a QoL thingy that just makes something a bit more user-friendly?

(Off/Meta-topic: I don't regard discussing your suggestion, its merits,
and alternatives as derailing a topic about your suggestion?)


Reply to this email directly or view it on GitHub
#1277 (comment)
.

@Inari-Whitebear
Copy link
Contributor

Hm, interesting idea. Though it has 1 input and 5 outputs. So only one case could input into the screen?

Unless you had like 2 of them, and only 1 was turned on, but then you'd have to communicate between the cases which draws to the screen or something?

@MyNameIsKodos
Copy link
Contributor Author

I don't think this is a good idea, but you could have an inverted mode, with 5 inputs and one output.

If anyone has any suggestions as to what that would be good for, I'm all ears.

@Inari-Whitebear
Copy link
Contributor

Well what comes to mind would be what they had at BTM, where they had the presentation running, but Sangar also placed a case to showcase stuff and the main screen could be switched between the 2.

But then again, that could be done by using the address memory stuff too

@Vexatos
Copy link
Contributor

Vexatos commented Jul 9, 2015

@Inari-Whitebear That's what I made the program I previously mentioned for. That presentation at BTM. And that's why this is a thing.

@Inari-Whitebear
Copy link
Contributor

I see one use for such a block: A (hardware) diode-like block (so, one-way-gate). Could still be implemented by having a PC or preferably MCU. But MCU aren't capable of that and PC might be overkill.

@fnuecke
Copy link
Member

fnuecke commented Nov 15, 2015

Due to how OC's networking works, one-way access to components isn't really possible, which, as I understand, this suggests? For dynamically switching subnets, there's the toggle cable thinger now.

@fnuecke fnuecke closed this as completed Nov 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants