Prelude... I'm not sure if this is in the correct sub-forum, so if not, please move it to where it belongs.
I was thinking of something. First off, is this even necessary? Is CALCnet's protocol vulnerable to a calculator (or other programmed hub) using the network to transmit stuff to a calculator and force the receiver to use it in a way not dictated by the current program?
I read in a C++ networking tutorial that a typical firewall operates by assigning a different IP address to your computer than your true IP address. When you "Allow" an activity, the firewall provides that program with your true IP address, thus allowing it to access your computer. When you "Deny" an activity, the firewall does not supply your true IP, thus the pending transmission gets "lost in cyberspace" and never makes it to your computer.
I was thinking that a similar tactic could be applied to CALCnet. A raised firewall would assign a fake "Calc ID" to your calculator to identify it on the network. If you choose to allow the incoming connection, the calc supplies your true Calc ID to the network and writes a "program identifier" code into the list of "allowed programs" so that you don't get repeatedly bothered by the firewall.
The caveats of this are...the network protocol would probably need to be redesigned in order to somehow wrap the data in a "program type" identifier, or force the designer of a CALCnet program to format his transmissions to include a program identifier. Also, I would need to figure out how CALCnet generates the Calc ID, so that it can be "interfered with" in order to generate the firewall Calc ID.
I'm curious to hear Kerm's take on this. I'm mostly presenting this just to see if my understanding of how a firewall works is correct?
I was thinking of something. First off, is this even necessary? Is CALCnet's protocol vulnerable to a calculator (or other programmed hub) using the network to transmit stuff to a calculator and force the receiver to use it in a way not dictated by the current program?
I read in a C++ networking tutorial that a typical firewall operates by assigning a different IP address to your computer than your true IP address. When you "Allow" an activity, the firewall provides that program with your true IP address, thus allowing it to access your computer. When you "Deny" an activity, the firewall does not supply your true IP, thus the pending transmission gets "lost in cyberspace" and never makes it to your computer.
I was thinking that a similar tactic could be applied to CALCnet. A raised firewall would assign a fake "Calc ID" to your calculator to identify it on the network. If you choose to allow the incoming connection, the calc supplies your true Calc ID to the network and writes a "program identifier" code into the list of "allowed programs" so that you don't get repeatedly bothered by the firewall.
The caveats of this are...the network protocol would probably need to be redesigned in order to somehow wrap the data in a "program type" identifier, or force the designer of a CALCnet program to format his transmissions to include a program identifier. Also, I would need to figure out how CALCnet generates the Calc ID, so that it can be "interfered with" in order to generate the firewall Calc ID.
I'm curious to hear Kerm's take on this. I'm mostly presenting this just to see if my understanding of how a firewall works is correct?
