+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: In Progress (https://forum.openredstone.org/forum-20.html)
+---- Thread: intOREnet (/thread-5661.html)
intOREnet - slugdude - 01-26-2015
As I'm sure some of you are aware, me and crazyninja2 have wanted to create a redstone network for a long time. This vision was shattered by chunk loading issues. But now, we have found a way. It is no longer a network, but an intOREnet! Now staff approved, should be pretty darn kewl. I will keep this thread updated on progress.
For those who don't know, any information can be transmitted via intOREnet, assuming it follows some set standards.
- Packets must be numbered. Due to routing, packets may not arrive in the order they were sent in.
- Packets must all use the same addressing standards. See the really long post on page 4 for more details.
- The data must must not exceed 4 bytes.
I would also like a list of people who a) don't mind the connection wires under their plot, b) who dont mind one of the switches under their plots, and c) who want to be connected to the intOREnet. There is now a public poll for this (Public polls are where people can see what each person voted for. If you check both "I want intOREnet" and "I don't want intOREnet", I have no choice to ignore it unless you rectify it at a later date, in the thread or in game.). Thanks to all those who have already allowed the construction of the network on some ore all of their plots! <3
Edit: May I add that you can invent your own protocols, as long as it follows the standards.
Edit 2: Naturally, if you have a switch, you have to have wires, and if you are connected, you need a switch and wires (not to mention a hub!)
THIS IS OUTDATED! PLEASE SEE https://forum.openredstone.org/showthread.php?tid=9174
RE: intOREnet - Nickster258 - 01-26-2015
At the moment staff has agreed that the 2x2 plot granted to you is the current limit of the network.
The staff are currently talking about the eligibility of expanding it onto more plots.
RE: intOREnet - Legofreak - 01-26-2015
so, how are you getting around the chunk loading issues now?
RE: intOREnet - slugdude - 01-26-2015
(01-26-2015, 08:35 PM)Nickster258 Wrote: 2x2 plot granted to you
I think you'll find that those are not my plots. They belong to crazy.
Yes, I am being pedantic. But a 2x2 plot isn't big enough for a whole internet, and I think it would be really cool. The 2x2 plot is just a LAN that crazy is building, connecting CPUs together.
Seriously, some of these inactive peeps literally no one has even heard of.
(01-26-2015, 09:17 PM)RekcirBrickeR Wrote: so, how are you getting around the chunk loading issues now?
Pistons at chunk borders load the chunk they point into, but not for long enough. We now have inverted pistons too
Have a look at the edge of my plot for the prototype.
RE: intOREnet - Chibill - 01-26-2015
how big are the data lines?
like pics please...
RE: intOREnet - slugdude - 01-26-2015
(01-26-2015, 11:09 PM)Chibill Wrote: how big are the data lines?
like pics please...
At the moment, pretty big, but I could easily make it smaller. I'll post some pics once I have done so.
RE: intOREnet - Crazyninja2000 - 01-26-2015
omfg slug. 2x2 plot is more the big enoug, saying that i can fit about 8 of my CPUs on one plot. people are welcome to connect there own CPUs. A map wide network is just ridiculous, the staff have been nice enough to give us some designated plots. I might expand the are if a ton of people want to be in the local network.
RE: intOREnet - Nuuppanaani - 01-26-2015
I have hard time seeing the advantage of having a map wide networks versus the 2x2 plot one you're already permitted to build.
RE: intOREnet - slugdude - 01-26-2015
chibill, this is as small as I could get them, that's a 1 chunk section of a wire. There will be 2 wires most likely.
![[Image: sH8IvXQ.png]](http://i.imgur.com/sH8IvXQ.png)
It's not about use, its about incredible awesomeness. Also, nuup, what use is a CPU in MC?
If you're going to say "well, we build it and know how it works irl", then why does that not apply to an internet?
(01-26-2015, 11:24 PM)Crazyninja2000 Wrote: give us
May I remind you that those are *your* plots, and that is actually separate from my project. You said it yourself, in chat.
RE: intOREnet - Crazyninja2000 - 01-27-2015
(01-26-2015, 11:50 PM)slugdude Wrote: chibill, this is as small as I could get them, that's a 1 chunk section of a wire. There will be 4 wires.
It's not about use, its about incredible awesomeness. Also, nuup, what use is a CPU in MC?
If you're going to say "well, we build it and know how it works irl", then why does that not apply to an internet?
(01-26-2015, 11:24 PM)Crazyninja2000 Wrote: give us
May I remind you that those are *your* plots, and that is actually separate from my project. You said it yourself, in chat.
first of all, i broke off from the project becuz a map wide network is ridiculous. first, we were going to use insta wire that lagged just as much and was faster(instantly faster). second, i thought you got that new plot next to me so that you could be connect to my local network? a local network is faster, easier, and less laggy.
RE: intOREnet - slugdude - 01-27-2015
(01-27-2015, 12:13 AM)Crazyninja2000 Wrote:(01-26-2015, 11:50 PM)slugdude Wrote: chibill, this is as small as I could get them, that's a 1 chunk section of a wire. There will be 4 wires.
<Image removed for space taken up reasons>
It's not about use, its about incredible awesomeness. Also, nuup, what use is a CPU in MC?
If you're going to say "well, we build it and know how it works irl", then why does that not apply to an internet?
(01-26-2015, 11:24 PM)Crazyninja2000 Wrote: give us
May I remind you that those are *your* plots, and that is actually separate from my project. You said it yourself, in chat.
first of all, i broke off from the project becuz a map wide network is ridiculous. first, we were going to use insta wire that lagged just as much and was faster(instantly faster). second, i thought you got that new plot next to me so that you could be connect to my local network? a local network is faster, easier, and less laggy.
1. Can we please not turn this into a petty argument
2. Instawire caused me to crash
3. I like a challenge. People don't do things because they are easy.
4. Yes, that is the reason I moved my plot, but not the only.
RE: intOREnet - Magic :^) - 01-27-2015
guys who cares about speed anyways. We don't need to stream netflix on it or anything.
A working internet is fine, even if it's slow. It could be hooked up to word processors for email.
I think the intOREnet would create more interest in single chunk systems, so we can have devices to receive data while we're not online
RE: intOREnet - Chibill - 01-27-2015
I hate insta wire don't remake cross plot.
RE: intOREnet - slugdude - 01-27-2015
(01-27-2015, 04:14 AM)Chibill Wrote: I hate insta wire don't remake cross plot.
I'm not going to be using instawire.
Unfortunately, the network relies on the receiver being online, although please feel free to experiment.
RE: intOREnet - Frontrider - 01-27-2015
(01-27-2015, 09:22 AM)slugdude Wrote: Unfortunately, the network relies on the receiver being online, although please feel free to experiment.
Why exactly the reciver needs to be loaded? (if the routing is not static. If dynamic, than i can understand.)
You might be able to increase speed if you use longer wires alongside the self chunk loading ones. tripwire can go for 40 blocks, if the persen is there than it will be faster.
RE: intOREnet - slugdude - 01-27-2015
(01-27-2015, 10:59 AM)Frontrider Wrote:(01-27-2015, 09:22 AM)slugdude Wrote: Unfortunately, the network relies on the receiver being online, although please feel free to experiment.
Why exactly the reciver needs to be loaded? (if the routing is not static. If dynamic, than i can understand.)
You might be able to increase speed if you use longer wires alongside the self chunk loading ones. tripwire can go for 40 blocks, if the persen is there than it will be faster.
It has nothing to do with the routing, it's just that repeaters and torches freeze in unloaded chunks. I can make the wire load for long enough to transfer the signal, but not the routers/switches. As I stated in my first post, I haven't decided exactly how the addresses will work, it may end up nothing like real life IP addresses.
RE: intOREnet - Noah7545 - 01-28-2015
Once I know how the protocol works I would like to make a memory (file) server for this. I hope the project comes along!
RE: intOREnet - LordDecapo - 01-28-2015
Don't mine wires going under my plots, not my set of 3x3 area that took me forever to convince that many people to let me use there plot spaces to make that xD... that is near the edge of world, and will be super laggy anyway.
So if u want to put wires through my older plots with the mansion, walls, and older version of IizR That is fine, just not my 3x3 area xD
RE: intOREnet - slugdude - 01-28-2015
(01-28-2015, 12:37 AM)Noah7545 Wrote: Once I know how the protocol works I would like to make a memory (file) server for this. I hope the project comes along!
The intOREnet is just a medium for signals to travel, you can invent your own protocol.
(01-28-2015, 06:17 AM)LordDecapo Wrote: Don't mine wires going under my plots, not my set of 3x3 area that took me forever to convince that many people to let me use there plot spaces to make that xD... that is near the edge of world, and will be super laggy anyway.
So if u want to put wires through my older plots with the mansion, walls, and older version of IizR That is fine, just not my 3x3 area xD
Ok
RE: intOREnet - Frontrider - 01-28-2015
(01-27-2015, 05:08 PM)slugdude Wrote:(01-27-2015, 10:59 AM)Frontrider Wrote:(01-27-2015, 09:22 AM)slugdude Wrote: Unfortunately, the network relies on the receiver being online, although please feel free to experiment.
Why exactly the reciver needs to be loaded? (if the routing is not static. If dynamic, than i can understand.)
You might be able to increase speed if you use longer wires alongside the self chunk loading ones. tripwire can go for 40 blocks, if the persen is there than it will be faster.
It has nothing to do with the routing, it's just that repeaters and torches freeze in unloaded chunks. I can make the wire load for long enough to transfer the signal, but not the routers/switches. As I stated in my first post, I haven't decided exactly how the addresses will work, it may end up nothing like real life IP addresses.
i know that you will need that wire.
i'm saying to use an alternative faster route if possible (the guy is on his plot and keeps it loaded). If not posible, use the self chunk loading one.
RE: intOREnet - slugdude - 01-28-2015
(01-28-2015, 04:25 PM)Frontrider Wrote:(01-27-2015, 05:08 PM)slugdude Wrote:(01-27-2015, 10:59 AM)Frontrider Wrote:(01-27-2015, 09:22 AM)slugdude Wrote: Unfortunately, the network relies on the receiver being online, although please feel free to experiment.
Why exactly the reciver needs to be loaded? (if the routing is not static. If dynamic, than i can understand.)
You might be able to increase speed if you use longer wires alongside the self chunk loading ones. tripwire can go for 40 blocks, if the persen is there than it will be faster.
It has nothing to do with the routing, it's just that repeaters and torches freeze in unloaded chunks. I can make the wire load for long enough to transfer the signal, but not the routers/switches. As I stated in my first post, I haven't decided exactly how the addresses will work, it may end up nothing like real life IP addresses.
i know that you will need that wire.
i'm saying to use an alternative faster route if possible (the guy is on his plot and keeps it loaded). If not posible, use the self chunk loading one.
Bear in mind that some plots will be quite a distance from each other, so there most likely unloaded chunks between them. The chunk loading wire only wastes one block in terms of signal strength, but it needs to be like that. I think it's an acceptable trade off for a wire that loads chunks.
RE: intOREnet - Noah7545 - 01-28-2015
Also, since there is only a 2 bit wire how can you have a packet number and a payload sent at once? or is it serial?
RE: intOREnet - slugdude - 01-29-2015
(01-28-2015, 11:29 PM)Noah7545 Wrote: Also, since there is only a 2 bit wire how can you have a packet number and a payload sent at once? or is it serial?
It's serial. There will be four wires, two each way. Two are for data transfer, the other two are for my RLCD that will determine if a router is available to send a signal to.
RE: intOREnet - Nickster258 - 01-29-2015
If half of the wires are dedicated to figuring out if a router can even receive data, you need to rethink the allocation of wires. My system runs off of 4 wires and upon an IP that doesn't match, rejects all other packets.
RE: intOREnet - Back_and_Black1 - 01-29-2015
crazy what exactly do you plan to have on your plot and who can build there?
RE: intOREnet - slugdude - 01-30-2015
(01-29-2015, 03:11 PM)Nickster258 Wrote: If half of the wires are dedicated to figuring out if a router can even receive data, you need to rethink the allocation of wires. My system runs off of 4 wires and upon an IP that doesn't match, rejects all other packets.
How else do you propose I do it?
RE: intOREnet - Nickster258 - 01-31-2015
Staff has discussed this and you are okay to continue on this project.
However, here are the conditions:
1. You can build on inactive plots as long as you ask the staff first and they grant you permission.
2. You can make the network of any size but if we see performance issues, we will ask you to either decrease the size of it or to remove it completely.
3. You are to respect the builds on the inactive plots. You cannot destroy any build on active or innactive plots.
Please be mindful of these conditions. They will be enforced by the staff team.
RE: intOREnet - Frontrider - 02-01-2015
You can come over and use the area under my plot, as long as you don't break the surface.
RE: intOREnet - slugdude - 02-01-2015
(01-31-2015, 08:20 PM)Nickster258 Wrote: Staff has discussed this and you are okay to continue on this project.
However, here are the conditions:
1. You can build on inactive plots as long as you ask the staff first and they grant you permission.
2. You can make the network of any size but if we see performance issues, we will ask you to either decrease the size of it or to remove it completely.
3. You are to respect the builds on the inactive plots. You cannot destroy any build on active or innactive plots.
Please be mindful of these conditions. They will be enforced by the staff team.
Thank you nick and other staff
Sure, Frontryder, everything is underground unless you say you want it above ground.
RE: intOREnet - PabloDons - 02-01-2015
I'd like to be connected, it's no problem for me as I got the space below my plot. So long I can't see a single redstone dust above the floor, different colored blocks, levers and buttons are cool
Edit: btw I suggest you make your net out of a block that isn't regularly used, that way it will be easy to remove large portions of the net if it poses performance issues
RE: intOREnet - Chibill - 02-02-2015
You can go under/thru my plot it won't be under ground but it will be tapped as a read only snooping test.
RE: intOREnet - slugdude - 02-03-2015
(02-02-2015, 03:24 AM)Chibill Wrote: You can go under/thru my plot it won't be under ground but it will be tapped as a read only snooping test.
Ummmmmm define "snooping test"
RE: intOREnet - Back_and_Black1 - 02-03-2015
no spies or stealing information on this internet.... or else we will have the government come after you....lolz
(p.s. ~ he's part of anonymous)
RE: intOREnet - Chibill - 02-03-2015
Reading that data and caching it for me to see what it is.
RE: intOREnet - Back_and_Black1 - 02-04-2015
slug can you come up with a standard for the intOREnet like bit layout can command i (or others) can start designing stuff to go with it. If you need help id gladly volunteer.
RE: intOREnet - LordDecapo - 02-04-2015
(02-01-2015, 10:59 PM)PabloDons Wrote: Edit: btw I suggest you make your net out of a block that isn't regularly used, that way it will be easy to remove large portions of the net if it poses performance issuesthis^
Makes a WE //replace a super easy way to delete if it causes issues
RE: intOREnet - Magic :^) - 02-04-2015
Might i suggest sponge then? Its only used for we points afaik
RE: intOREnet - LordDecapo - 02-05-2015
(02-04-2015, 09:50 PM)The Magical Gentleman Wrote: Might i suggest sponge then? Its only used for we points afaik
RE: intOREnet - slugdude - 02-06-2015
(02-03-2015, 11:31 PM)Back_and_Black1 Wrote: no spies or stealing information on this internet.... or else we will have the government come after you....lolz
(p.s. ~ he's part of anonymous)
^ this
(02-03-2015, 11:55 PM)Chibill Wrote: Reading that data and caching it for me to see what it is.
That won't work. The address is decoded in stages, two bits for each switch it passes. There is no way of telling how many bits of the address are still remaining, therefore the data cannot be discerned from the address. The data can be any length so long as it doesn't exceed (x) bits. I'm still unsure on that but I think I'm settling for 4 bytes. Edit: This paragraph is BS as this has changed.
(02-04-2015, 01:51 AM)Back_and_Black1 Wrote: slug can you come up with a standard for the intOREnet like bit layout can command i (or others) can start designing stuff to go with it. If you need help id gladly volunteer.
The only standards are those defined in the first post. However may I add that the max data size is probably going to be 4 bytes (per each packet), and addresses will be 8 bytes (although probably easier to display this as hex, since "my address is 9E" is much easier to remember than "my address is 10011110"). The intOREnet is simply a medium for communication to travel, you can invent your own protocols. Wanna make an SSH like connection to your CPU? Go for it! Wanna encrypt all your data? Why not? Wanna make a primitive webpage server? YOLO! Wanna upload illegal pornography? Probably best not to...
(02-04-2015, 09:50 PM)The Magical Gentleman Wrote: Might i suggest sponge then? Its only used for we points afaik
Thanks for the suggestion, I'll do this for now. Local areas will be other blocks for aesthetic reasons, but all the public switches and interconnecting wires will have spnge.
*Deep breath*
Here's an example of how I think the packets will look when sent from the sending device. They may look different as they travel since switches need to manipulate the address.
(Lead bit)(8 bit address)(lead bit maybe)(4 bit packet number)(lead bit maybe)(8 bit source address)(lead bit)(4 bytes max data)
So in binary looking like
1000000001000010000000010000........
The dots are where the data can extend. The overall Max size of the packet would be 7 bytes (the first three are the addresses and packet number and lead bits, the remaining 4 is the data).
If the data ends in a bunch o' 0s, then even though the device doesn't actively receive them, it can assume they are there.
As for where I have written " maybe" it's where I haven't decided yet.
And yes, I said "byte" purposefully.
RE: intOREnet - LordDecapo - 02-06-2015
So how long would the 7bytes take to trasmit?
RE: intOREnet - slugdude - 02-06-2015
(02-06-2015, 09:49 PM)LordDecapo Wrote: So how long would the 7bytes take to trasmit?
If you mean 7 bytes overall (I.e. one complete packet) then that is just the speed of the network (see first post).
If you mean 7 bytes of data, then that would be transmitted in two packets, 4 bytes in the first, 3 in the second. How quickly you send these one after another depends, but please leave a gap between them or you will break the switches. But how quickly they arrive depends on the state of the network, which switches are available etc.
RE: intOREnet - LordDecapo - 02-07-2015
Kk, cool. I missed that part when I first read it xD
RE: intOREnet - Phase - 02-08-2015
I find the whole thing useless, why on earth do we need a bunch of lag-wires underneath every plot on the server? It's laggy enough. We don't need to "connect" with anything.
RE: intOREnet - Magic :^) - 02-08-2015
the 'lag-wires' aren't going under every plot on the server - note the poll on the top of this page.
One of the main uses for the CPU I'm working on is for connecting to the network. I have a few plans on what to use the network for.
I honestly don't know why people are so against these wires... It's fine if you don't want them on your plot, and it was agreed that if they cause lag they will be removed. I don't know what's left to complain about, unless the nay-sayers just don't want other people connected just because.
RE: intOREnet - Nickster258 - 02-08-2015
https://www.youtube.com/watch?v=ussCHoQttyQ
RE: intOREnet - LordDecapo - 02-09-2015
*links something else to derail thread further*
RE: intOREnet - slugdude - 02-09-2015
Plz don't derail this.
The first wire is under construction!
It will start at my plot, cross the corner of Nick's plot with the redstone underneath and reach a switch on alt's plot. It will then continue, across another corner of Nick's plot, underneath his plot with a solid floor, under an inactive plot, then reaching another switch on magic's plot.
RE: intOREnet - GISED_Link - 02-09-2015
Is there a map of the server ? For knowing if I'm lucky enough to be connected one day, too
RE: intOREnet - slugdude - 02-09-2015
(02-09-2015, 11:11 PM)GISED_Link Wrote: Is there a map of the server ? For knowing if I'm lucky enough to be connected one day, too
There is a copy of the map at spawn on my plot showing all the plots I have permission to build on. I will add wires and switches to it upon completion of each wire/switch.
A little more info about switches and hubs:
A switch has 4 maximum connection to other switches or hubs. They will be interconnected around the map, and if one is unavailable they will attempt to route around the issue. Due to this, packets may not arrive in the order they are sent in if a packet is sent and routed around a longer route due to an unloaded switch, then a second packet is sent straight afterwards, but this time someone has logged on and the previously unavailable switch becomes availible, and the second packet is sent down a faster route to the destination, it may arrive before the first packet does. This is why packets must have numbers, so that they can be stitched together by the receiving device. This may be done at hubs but I haven't decided yet.
Hubs are very similar to switches. They have 4 maximum connection. One of them must be to a nearby switch within render distance. The other three are available to be connected to devices like CPUs or messaging systems, servers whatever. Hubs have no RLCD since all the things they directly interact with are nearby. All those who want to be connected will have a switch and hub placed on their plots. I have the base components to build these but are not fully assembled yet.
A final question for the staff:
If someone connects an 'innapropriate device' to the network, I.e. a comparator clock, or a packet generator that is causing lag and damage, do I have the right to disconnect (not delete) it?
RE: intOREnet - Nickster258 - 02-09-2015
(02-09-2015, 11:30 PM)slugdude Wrote: A final question for the staff:
If someone connects an 'innapropriate device' to the network, I.e. a comparator clock, or a packet generator that is causing lag and damage, do I have the right to disconnect (not delete) it?
Oh, but of course.
Ninja: if the device has malicious intent, delete it.
RE: intOREnet - slugdude - 02-09-2015
(02-09-2015, 11:34 PM)Nickster258 Wrote:(02-09-2015, 11:30 PM)slugdude Wrote: A final question for the staff:
If someone connects an 'innapropriate device' to the network, I.e. a comparator clock, or a packet generator that is causing lag and damage, do I have the right to disconnect (not delete) it?
Oh, but of course.
OK thank you.
RE: intOREnet - Nickster258 - 02-09-2015
(02-09-2015, 11:35 PM)slugdude Wrote: Nicksjter258
K
RE: intOREnet - slugdude - 02-09-2015
(02-09-2015, 11:39 PM)Nickster258 Wrote:(02-09-2015, 11:35 PM)slugdude Wrote: Nicksjter258
K
What the fuck u talking about man
RE: intOREnet - Magic :^) - 02-10-2015
Looks like the network's shaping up nicely!Is it just a matter of placing the wires and switches now, or are you still designing stuff?
RE: intOREnet - slugdude - 02-10-2015
(02-10-2015, 12:20 AM)The Magical Gentleman Wrote:
Is it just a matter of placing the wires and switches now, or are you still designing stuff?
Mainly placing wires. I need to cobble the switches together but like I said, I already have the base parts that they will consist of.
Also, sponge looks fugly. Any other better unused blocks?
RE: intOREnet - Tjakka5 - 02-10-2015
Command blocks?
Also, I would love to be connected ^^
RE: intOREnet - slugdude - 02-10-2015
(02-10-2015, 11:01 AM)Tjakka5 Wrote: Command blocks?
No.
(02-10-2015, 11:01 AM)Tjakka5 Wrote: Also, I would love to be connected ^^
Cool.
On another note, the plans for the first wire have changed. It will start at my plot, head straight for tj's plot, and there will be a switch there. It will then continue to alt's plot, and the rest is the same as before.
Although TJ hasn't said I can build in this thread, he said it in game. I screenshotted it if you wanna see it nick (I wanna have evidence of each person who has given me perms)
RE: intOREnet - Curiosity85 - 02-14-2015
If people start giving each other files (such as messages), any chance of malware in them? Because I would not want a computer that I spent tons of time on (In school server, so don't have any now) to have all of its files fucked up.
RE: intOREnet - LordDecapo - 02-14-2015
(02-14-2015, 03:24 AM)Curiosity85 Wrote: If people start giving each other files (such as messages), any chance of malware in them? Because I would not want a computer that I spent tons of time on (In school server, so don't have any now) to have all of its files fucked up.
No....
Well its possible, but the person would have to know everything about your system and you must have a shared Data and Inst RAM for info to transfer over. But most CPUs on here have no su changes ability yet
RE: intOREnet - Nuuppanaani - 02-14-2015
(02-14-2015, 02:12 PM)LordDecapo Wrote:(02-14-2015, 03:24 AM)Curiosity85 Wrote: If people start giving each other files (such as messages), any chance of malware in them? Because I would not want a computer that I spent tons of time on (In school server, so don't have any now) to have all of its files fucked up.
No....
Well its possible, but the person would have to know everything about your system and you must have a shared Data and Inst RAM for info to transfer over. But most CPUs on here have no su changes ability yet
LMAO!
Making a virus would be quite of an accomplishment tho
RE: intOREnet - Nickster258 - 02-14-2015
For some reason I now want to join the network just so I can make a virus...
RE: intOREnet - slugdude - 02-14-2015
(02-14-2015, 03:24 AM)Curiosity85 Wrote: malware
(02-14-2015, 04:24 PM)Nuuppanaani Wrote: virus
(02-14-2015, 05:47 PM)Nickster258 Wrote: virus
May I maintain that I am responsible for the upkeep and maintenance of the infrastructure that is intOREnet. I will not claim any responsibility for malware caused by users of intOREnet. May I advise some sort of antivirus built into vulnerable devices connected to intOREnet? I would also like to hear staff's opinions on cyber-cyber-crime.
On a more positive note, the plans for the switches/hubs have been made, they are very much the same, just that RLCD OUT should be connected directly to RLCD IN for the connection which are end devices (not a switch) on the hubs, since devices connected will not have RLCDs. It is just a matter of building the switches and laying wires now
Regarding port multipliers: There will be no official support for these, but they can act like devices, which then direct packets to further devices. The addresses used for these must be inside the data section of the standards or it will screw around with the rest of the network. Sending packets that do not follow the standards may cause undesirable results.
RE: intOREnet - Tommyand - 02-17-2015
It would be sort of neat to see a computer that got a virus... in a game being run by a computer...
Now I want to make a machine where the contents of ram are executable... Eventually...
Back on to what I was going to say, if/when I become a member of the build server, I give permission for routers, wires, etc... I wouldn't mind if part of it were above ground, either. And, at some point I'd like to hook something up to the intOREnet. But that'll probably be a while. Just giving advanced notice.
RE: intOREnet - Phase - 02-17-2015
Dude, I'm going to spam everyone with an ASCII dick.
RE: intOREnet - LordDecapo - 02-18-2015
(02-17-2015, 08:37 AM)Phasesaber Wrote: Dude, I'm going to spam everyone with an ASCII dick.
Lol
I will have RAM connected that can be executable.. and written to over a network...
so u could hack into it if u timed an interrupt properly.. through the network.. and network converter (IizRwebs will run different formats then IntOREnet, but my network will have a conversion system
RE: intOREnet - slugdude - 02-19-2015
(02-17-2015, 08:37 AM)Phasesaber Wrote: Dude, I'm going to spam everyone with an ASCII dick.
All packets containing an ASCII dick will now be denied by the switches at a hardware level.
Jk
(02-18-2015, 04:21 AM)LordDecapo Wrote:(02-17-2015, 08:37 AM)Phasesaber Wrote: Dude, I'm going to spam everyone with an ASCII dick.
Lol
I will have RAM connected that can be executable.. and written to over a network...
so u could hack into it if u timed an interrupt properly.. through the network.. and network converter (IizRwebs will run different formats then IntOREnet, but my network will have a conversion system
Prehaps authenticate before writing any and all data to ram to be executed?
I just had an idea - encrypted transfer between you and a CPU. You send instruction, CPU executes, returns a confirmation and any output. Dat would be keel
Here's my opinion on viruses and other shady shit:
You can do it as long as you have the target's permission (for tests and shit)
RE: intOREnet - greatgamer34 - 02-20-2015
I would like to be connected to this, just not at my 1x2 plot with the cool floor. Ill take the hardware at /pwarp great If you could have it near the purple side that'd be cool.
RE: intOREnet - slugdude - 02-20-2015
(02-20-2015, 02:41 AM)greatgamer34 Wrote: I would like to be connected to this, just not at my 1x2 plot with the cool floor. Ill take the hardware at /pwarp great If you could have it near the purple side that'd be cool.
That's cool, but it'll take a while to build these switches, I may hold it off till we get the 1.8 server.
RE: intOREnet - Magic :^) - 03-31-2015
1.8 is coming soon ™...
Will you be continuing your work?
RE: intOREnet - slugdude - 03-31-2015
(03-31-2015, 03:10 PM)MagicalGentleman Wrote: 1.8 is coming soon ™...
Will you be continuing your work?
Yes
If anyone wants to help me that would be great since the switches still need to be built. The next thing I need is some write-once memory. I made a change or to to how addressing will work but nothing major. I need a memory bank that will:
1. Write 8 bits of data in the next available slot
2. When it receives 6 bits of data in a different input, it will search for a byte of memory that has those 6 bits in the first 6 bits of it, then output the last 2 bits of that byte.
RE: intOREnet - slugdude - 03-31-2015
(02-14-2015, 10:31 PM)slugdude Wrote: Regarding port multipliers: There will be no official support for these, but they can act like devices, which then direct packets to further devices. The addresses used for these must be inside the data section of the standards or it will screw around with the rest of the network. Sending packets that do not follow the standards may cause undesirable results.
Due to the way switches work, you can have an extra switch(es) on your plot if you want one (So that you can have more than 3 devices) but they will have different addresses.
The 8-bit addresses are now in two parts.
000000 00
The first 6 is the address of your hub. The last two are which port on the hub the destination device is connected to. This saves space in the switch memory since it only needs to store the first 6 bits, and the two-bit direction, a total of 8 bits. Before, each set of memory would have to store 8 bits plus the 2 bit direction (10 bits).
This does, however, mean that the maximum number of hubs connected to the network is 63. You cannot have an address of 000000XX because that is the address used for the assigning of an an address to a hub. (The hub will send a packet with address 00000000 and a manually set source address to it's switch, which will remember the address and where it came from, and resend that packet to other switches.)
RE: intOREnet - slugdude - 04-05-2015
What I said previously about people who are connected needing both a hub and a switch (can't find the quote), is now obsolete. Thanks to awesome 1.8ness this is no longer the case, and you only need a hub on your plot as long as there is a switch nearby. It doesn't have to be on your plot anymore, but doing so may decrease latency. (Less distance for signal to travel).
Also, that snooping test could work, chibill, as that method of addressing was dropped a while ago, I forgot to tell you.
About this 1.8ness, I'm going to talk about it in another thread since it is an issue by itself. It regards how redstone now automatically loads chunks it is attempting to cause updates in, meaning clocks (and CPUs) could be left running. Please don't talk about this here, I'll make a dedicated thread in the Build discussion section.
RE: intOREnet - tokumei - 04-05-2015
(02-14-2015, 04:24 PM)Nuuppanaani Wrote:(02-14-2015, 02:12 PM)LordDecapo Wrote:(02-14-2015, 03:24 AM)Curiosity85 Wrote: If people start giving each other files (such as messages), any chance of malware in them? Because I would not want a computer that I spent tons of time on (In school server, so don't have any now) to have all of its files fucked up.
No....
Well its possible, but the person would have to know everything about your system and you must have a shared Data and Inst RAM for info to transfer over. But most CPUs on here have no su changes ability yet
LMAO!
Making a virus would be quite of an accomplishment tho
Challenge accepted.
But as Decapo said, you'd essentially have to have a Von Neumann architecture in order to execute arbitrary instructions. The most you could do is data corruption otherwise.
RE: intOREnet - slugdude - 04-05-2015
(04-05-2015, 02:49 PM)NonemuNinja Wrote:(02-14-2015, 04:24 PM)Nuuppanaani Wrote:(02-14-2015, 02:12 PM)LordDecapo Wrote:(02-14-2015, 03:24 AM)Curiosity85 Wrote: If people start giving each other files (such as messages), any chance of malware in them? Because I would not want a computer that I spent tons of time on (In school server, so don't have any now) to have all of its files fucked up.
No....
Well its possible, but the person would have to know everything about your system and you must have a shared Data and Inst RAM for info to transfer over. But most CPUs on here have no su changes ability yet
LMAO!
Making a virus would be quite of an accomplishment tho
Challenge accepted.
:o
RE: intOREnet - Chibill - 04-05-2015
Well with lord's CPU you could write viruses that can be made to infect any computer connected to it.
RE: intOREnet - LordDecapo - 04-05-2015
(03-31-2015, 04:36 PM)slugdude Wrote:(03-31-2015, 03:10 PM)MagicalGentleman Wrote: 1.8 is coming soon ™...
Will you be continuing your work?
Yes
If anyone wants to help me that would be great since the switches still need to be built. The next thing I need is some write-once memory. I made a change or to to how addressing will work but nothing major. I need a memory bank that will:
1. Write 8 bits of data in the next available slot
2. When it receives 6 bits of data in a different input, it will search for a byte of memory that has those 6 bits in the first 6 bits of it, then output the last 2 bits of that byte.
I have a tilable version of this same hardware, will have to show you where. Or u can modify Tuchis Cache to hold data via address rather then shifting.
also the way my CPU now connects to a network it's paged based, so every 16ticks you can send 64bits.
makes it good for being able to send instructions to 1 CPU to another and make slaves run smaller functions (that could fit in the Instriction Cache). Will make Pokémon fun to play over a network cause u will only need 1 packet per turn. What is the best way that you think I can send page data via ur network? Will I have to spit it up into multiple smaller packets?
RE: intOREnet - slugdude - 04-05-2015
(04-05-2015, 06:34 PM)LordDecapo Wrote:(03-31-2015, 04:36 PM)slugdude Wrote:(03-31-2015, 03:10 PM)MagicalGentleman Wrote: 1.8 is coming soon ™...
Will you be continuing your work?
Yes
If anyone wants to help me that would be great since the switches still need to be built. The next thing I need is some write-once memory. I made a change or to to how addressing will work but nothing major. I need a memory bank that will:
1. Write 8 bits of data in the next available slot
2. When it receives 6 bits of data in a different input, it will search for a byte of memory that has those 6 bits in the first 6 bits of it, then output the last 2 bits of that byte.
I have a tilable version of this same hardware, will have to show you where. Or u can modify Tuchis Cache to hold data via address rather then shifting.
also the way my CPU now connects to a network it's paged based, so every 16ticks you can send 64bits.
makes it good for being able to send instructions to 1 CPU to another and make slaves run smaller functions (that could fit in the Instriction Cache). Will make Pokémon fun to play over a network cause u will only need 1 packet per turn. What is the best way that you think I can send page data via ur network? Will I have to spit it up into multiple smaller packets?
64 bits = 8 bytes
intOREnet packet = 4 bytes o' data
Therefore it could be split over 2 packets.
RE: intOREnet - fluffy406 - 04-06-2015
I will help
RE: intOREnet - LordDecapo - 04-06-2015
Oh 2 packets ain't bad!
RE: intOREnet - tokumei - 04-06-2015
I want to be connected. Beware that I may hack your hardware and make it a bridge between intOREnet and MDP
RE: intOREnet - LordDecapo - 04-06-2015
Who's hardware? Lol u gonna hack IizR to be a reroute location and cause mass havoc in the system with out ppl knowing it's u? Lol
RE: intOREnet - tokumei - 04-07-2015
nah, I mean "hack" by "take apart and put back together with extra parts for converting between protocols"
RE: intOREnet - slugdude - 04-07-2015
(04-07-2015, 03:21 AM)NonemuNinja Wrote: nah, I mean "hack" by "take apart and put back together with extra parts for converting between protocols"
I don't know why but probably mainly because I'm self-taught in redstone, but my stuff is pretty weird and crappily built so good luck m8
RE: intOREnet - jxu - 04-08-2015
idk how many times server internet is tried, no one is active long enough for it to ever be completed
RE: intOREnet - tokumei - 04-08-2015
That's why I'm making my own independent network. If intOREnet falls through the floor, it won't affect me and my communication. If my personal network falls through because of my own inactivity, it won't affect anyone else.
RE: intOREnet - Magic :^) - 04-08-2015
^ as long as at least ONE person gets some form of standardised network going, I'm happy xD
my lifelong dream of running a minecraft pr0n server is almost complete...
RE: intOREnet - Hastumer - 04-08-2015
Butt you need a special program for you CPUs and stuffz?
RE: intOREnet - tokumei - 04-08-2015
There's nothing stopping you if you want to include network capabilities in your instruction set. But for others, there may be lower-level ways to do the same thing (like memory mapping)
EDIT in case I interpreted wrong:
Yeah, I'm assuming you'd have to write your own client programs. Since we use so many different instruction sets, it's hard to distribute a standard program for a server-wide project like this.
RE: intOREnet - slugdude - 04-11-2015
So I'm taking a break from Minecraft until my exams are over, but intOREnet development will continue in my head and my notepad in my spare moments.
Two final notes, due to the large amount of switches required, it is highly unlikely that there will be enough loaded at one given time for the network to be viable. There is a bug with hoppers on 1.8 that will allow me to load an area. Unfortunately, this cannot be switched on and off easily as demand changes. The most control is the ability to shut down and turn on large segments of the network, from my plot, within spawn chunks. When I return and when I have built these switches, I will use this to ensure reliability of intOREnet, so long as staff are OK with it.
The other note is that due to interest in protocol designing, here are the 'set in stone' specifications of how the switches will handle data.
1 000000 00 1 000000 00 1 0000 1 00000000000000000000000000000000
All the 1's are lead bits. Some of them are in the middle because of how the switches and hubs interpret the packets.
The first 6 0's is the destination hub's address. This is assigned to you when the hub is connected to intOREnet and cannot be changed.
The next 2 is which physical port on the hub the destination device is connected to. This could change if you change what port it is connected to (There will be 4 ports, 00, 01, 10 and 11, allowing 4 devices per hub. If people have a plot next to each other and only intend to have one or two devices the I recommend that they share a hub, since only 63 hubs [Maybe one more, maybe one less] can be connected to intOREnet). These two sections make up the destination address.
The next 6 and two is as above, except this is the source address and port.
The next 4 is the packet number. Since, because of routing, packets may arrive in a different order, and data may expand over two or more packets, packets must be numbered so that the receiving hubs can put them in the correct order before sending the devices the data. At the start of a single continuous stream of data, the packet number will be 0000. The next packet will have packet number 0001. Then 0010, then 0011, etc. When you are finished, the last packet MUST have absolutely NO data in it. This is so that the hubs know that this is the end of the data and there are no more packets to be received. When you send the next set of data again, start from 0000 again. Once a hub has received all packet numbers between 0000 and whatever number is no data, it will send the data to the device.
The next 32 (4 bytes) is the data. You can put ANYTHING in here, as the switches will not modify it's contents. It is up to you to decide how your devices should interpret the data. However, once your data has ended, you NEED to send a packet with no data.
Once the packets have finished being sent, switched, transferred, and stitched together, the hub will proceed to send this information to the correct device in the following way:
1 000000 00 1 00000000000000000000000000000000
It strips out all the unnecessary sections for the end device.
The 1's, as before, are leads.
The 6 then 2 are the source address.
The 32 is the data.
All packets received by the end devices will be in the correct order already. A packet with no data in it will be sent last to the device.
Sending data will take the exact same format as above, except instead of source address, it's destination address, and between the source address and the data is a lead bit and the 4 bit packet number. Your hub will add the rest automatically. (the source address). A packet addressed to 111111 XX will be treated like a local address (like 192.168.X.X) and can be used to communicate locally to devices on your LAN. The XX is which port the device is connected to.
So you can come up with any way, format etc. of sending different types of data so long as it conforms as above. Feel free to ask questions but I cannot guarantee I will answer it.
I will return some time after the 15th of June.
-Slug
RE: intOREnet - GISED_Link - 04-12-2015
This thread contains a lot of "blablabla" ...
It's impossible to follow all the ideas here and it miss a lot of graphical elements. Maybe you can be inspired by a format like the RFC (http://en.wikipedia.org/wiki/Request_for_Comments)
I'm sure a lot of people want to help you (like me), but for the moment I think it's not complete about the main informations. I need detailed explanations about wich layer you are talking about, how each layer works, a good and clear spereation for each layer and some pic' to support your explanation.
Here you will found some examples (for everybody) :
OSI model : http://en.wikipedia.org/wiki/OSI_model
ip datagram (layer 3) : http://www.linktionary.com/i/ip3.jpg
rfc917 : http://tools.ietf.org/html/rfc917
RS232 (layer 1 only) : http://www.bnoack.com/graphics/rs232data.gif
TCP (layer 4), connection diagram: http://upload.wikimedia.org/wikipedia/commons/6/6c/Tcp_connect.svg
If you can give us picture like this, it would be perfect. And Maybe update the first post with the current final description.
RE: intOREnet - slugdude - 04-12-2015
(04-12-2015, 01:48 PM)GISED_Link Wrote: This post contains a lot of "blablabla" ...
It's impossible to follow all the ideas here and it miss a lot of graphical elements. Maybe you can be inspired by a format like the RFC (http://en.wikipedia.org/wiki/Request_for_Comments)
I'm sure a lot of people want to help you (like me), but for the moment I think it's not complete about the main informations. I need detailed explanations about wich layer you are talking about, how each layer works, a good and clear spereation for each layer and some pic' to support your explanation.
Here you will found some examples (for everybody) :
OSI model : http://en.wikipedia.org/wiki/OSI_model
ip datagram (layer 3) : http://www.linktionary.com/i/ip3.jpg
rfc917 : http://tools.ietf.org/html/rfc917
RS232 (layer 1 only) : http://www.bnoack.com/graphics/rs232data.gif
TCP (layer 4), connection diagram: http://upload.wikimedia.org/wikipedia/commons/6/6c/Tcp_connect.svg
If you can give us picture like this, it would be perfect. And Maybe update the first post with the current final description.
w0t
I don't even know what you're talking about m8.
RE: intOREnet - Hastumer - 04-12-2015
Slug, you wanted a single write RAM? Remove redstone with piston or make repeater lock so you can't input write anymore
RE: intOREnet - GISED_Link - 04-12-2015
(04-12-2015, 03:15 PM)slugdude Wrote:(04-12-2015, 01:48 PM)GISED_Link Wrote: This thread contains a lot of "blablabla" ...
It's impossible to follow all the ideas here and it miss a lot of graphical elements. Maybe you can be inspired by a format like the RFC (http://en.wikipedia.org/wiki/Request_for_Comments)
I'm sure a lot of people want to help you (like me), but for the moment I think it's not complete about the main informations. I need detailed explanations about wich layer you are talking about, how each layer works, a good and clear spereation for each layer and some pic' to support your explanation.
Here you will found some examples (for everybody) :
OSI model : http://en.wikipedia.org/wiki/OSI_model
ip datagram (layer 3) : http://www.linktionary.com/i/ip3.jpg
rfc917 : http://tools.ietf.org/html/rfc917
RS232 (layer 1 only) : http://www.bnoack.com/graphics/rs232data.gif
TCP (layer 4), connection diagram: http://upload.wikimedia.org/wikipedia/commons/6/6c/Tcp_connect.svg
If you can give us picture like this, it would be perfect. And Maybe update the first post with the current final description.
w0t
I don't even know what you're talking about m8.
It wasn't about only your post, but the thread in general ^^. So I've replaced post by thread ...
RE: intOREnet - slugdude - 04-12-2015
(04-12-2015, 07:22 PM)GISED_Link Wrote:(04-12-2015, 03:15 PM)slugdude Wrote:(04-12-2015, 01:48 PM)GISED_Link Wrote: This thread contains a lot of "blablabla" ...
It's impossible to follow all the ideas here and it miss a lot of graphical elements. Maybe you can be inspired by a format like the RFC (http://en.wikipedia.org/wiki/Request_for_Comments)
I'm sure a lot of people want to help you (like me), but for the moment I think it's not complete about the main informations. I need detailed explanations about wich layer you are talking about, how each layer works, a good and clear spereation for each layer and some pic' to support your explanation.
Here you will found some examples (for everybody) :
OSI model : http://en.wikipedia.org/wiki/OSI_model
ip datagram (layer 3) : http://www.linktionary.com/i/ip3.jpg
rfc917 : http://tools.ietf.org/html/rfc917
RS232 (layer 1 only) : http://www.bnoack.com/graphics/rs232data.gif
TCP (layer 4), connection diagram: http://upload.wikimedia.org/wikipedia/commons/6/6c/Tcp_connect.svg
If you can give us picture like this, it would be perfect. And Maybe update the first post with the current final description.
w0t
I don't even know what you're talking about m8.
It wasn't about only your post, but the thread in general ^^. So I've replaced post by thread ...
Still don't know what you're talking about in that post -.-
RE: intOREnet - GISED_Link - 04-12-2015
I wich that you write a main post where everybody can find easily where you project is now and where it goes. To do that, I wich that you create some pictures like my examples to illustrate your words. Because your are talking about :
- packet number
- physical port (routers)
- some connections protocol ("At the start of a single continuous stream of data, the packet number will be 0000")
- source address (routing)
- layer 1 protocol ("There will be four wires, two each way")
- and more
I think it's a good project and I'm sure a lot of people will use intOREnet. The problem is that you have said a lot of informations in several posts. So we (and maybe you ?) will always misunderstand something because we will not alway search the information in 10 posts.
So you can devide intOREnet into layers. The layers are defined in the OSI model. If you define clearly what layer do what, wich component of intOREnet is for wich layer etc., it will really simplify the life of everybody. What I suggest to make clearer :
- Layer 1 : physical. Describe the size of the packet (8 bit, 10 bit, etc...) and how to seperate and validate each packet (start bit, stop bit, etc...)
- how many diffrent layer 1 protocol will be supported (maybe only one ?)
- Layer 2 : Data Link. How you will send more than one packet between 2 routers or 2 devices directly connected (MAC adress ?)
- layer 3 : network. How intOREnet will send a packet form A to C and where is the best path/route, how your routers will learn the routes ? (ARP request ?, IP adress ?)
- layer 4 : Transport. How your numbered packet are transfered, how to open a session (if this exists), etc. (TCP ?, UDP ?)
The message I will give to you is : Please take time to make the things clearer for everyone. The pictures don't need to be beautiful; useful is enough. With this, we will begin faster to create some devices for intOREnet and help you to expand the network.
Are my words more understable now ?
RE: intOREnet - LordDecapo - 04-13-2015
I agree to ^ we need a new thread with more solidified plans.
RE: intOREnet - Apuly - 04-13-2015
I'd say that implementing the would be pretty useless.
Redstone is a lot more reliable than real-life networking cables, en because the speed is slow as fuck,it would only slow everything down
RE: intOREnet - slugdude - 04-14-2015
(04-12-2015, 11:12 PM)GISED_Link Wrote: I wich that you write a main post where everybody can find easily where you project is now and where it goes. To do that, I wich that you create some pictures like my examples to illustrate your words. Because your are talking about :
- packet number
- physical port (routers)
- some connections protocol ("At the start of a single continuous stream of data, the packet number will be 0000")
- source address (routing)
- layer 1 protocol ("There will be four wires, two each way")
- and more
I think it's a good project and I'm sure a lot of people will use intOREnet. The problem is that you have said a lot of informations in several posts. So we (and maybe you ?) will always misunderstand something because we will not alway search the information in 10 posts.
So you can devide intOREnet into layers. The layers are defined in the OSI model. If you define clearly what layer do what, wich component of intOREnet is for wich layer etc., it will really simplify the life of everybody. What I suggest to make clearer :
- Layer 1 : physical. Describe the size of the packet (8 bit, 10 bit, etc...) and how to seperate and validate each packet (start bit, stop bit, etc...)
- how many diffrent layer 1 protocol will be supported (maybe only one ?)
- Layer 2 : Data Link. How you will send more than one packet between 2 routers or 2 devices directly connected (MAC adress ?)
- layer 3 : network. How intOREnet will send a packet form A to C and where is the best path/route, how your routers will learn the routes ? (ARP request ?, IP adress ?)
- layer 4 : Transport. How your numbered packet are transfered, how to open a session (if this exists), etc. (TCP ?, UDP ?)
The message I will give to you is : Please take time to make the things clearer for everyone. The pictures don't need to be beautiful; useful is enough. With this, we will begin faster to create some devices for intOREnet and help you to expand the network.
Are my words more understable now ?
I will try and work on this at some point.
RE: intOREnet - Hastumer - 05-17-2015
Slug, because I'm Builder now, I would like to join when it get's started.
RE: intOREnet - slugdude - 05-17-2015
(05-17-2015, 09:54 AM)Hastumer Wrote: Slug, because I'm Builder now, I would like to join when it get's started.
Sure. Don't forget you need to claim a plot as close to me as possible for best chances at being connected.
RE: intOREnet - fluffy406 - 05-18-2015
wait till ya see RedNet
RE: intOREnet - LordDecapo - 05-19-2015
(05-18-2015, 06:41 AM)fluffy406 Wrote: wait till ya see RedNet
Or RegNet
RE: intOREnet - Magic :^) - 05-22-2015
Can't wait for NetNet
RE: intOREnet - tokumei - 05-22-2015
And MetaNet
RE: intOREnet - Hastumer - 05-24-2015
How's about intOREnet? Wait...
RE: intOREnet - slugdude - 06-16-2015
Since I have now returned to the server, I will be continuing development of intOREnet. I'm sorry I was absent from ingame for so long, but I had exams which take priority over redstone. I'm still building the switches.
RE: intOREnet - Halflife390 - 06-16-2015
(06-16-2015, 07:35 PM)slugdude Wrote: Since I have now returned to the server, I will be continuing development of intOREnet. I'm sorry I was absent from ingame for so long, but I had exams which take priority over redstone. I'm still building the switches.
Is this being built on the 1.8 world?
RE: intOREnet - Apuly - 06-17-2015
>internet
>switches
Gg
RE: intOREnet - slugdude - 07-01-2015
(06-16-2015, 08:51 PM)Halflife390 Wrote:(06-16-2015, 07:35 PM)slugdude Wrote: Since I have now returned to the server, I will be continuing development of intOREnet. I'm sorry I was absent from ingame for so long, but I had exams which take priority over redstone. I'm still building the switches.
Is this being built on the 1.8 world?
Yes, it is.
Do not fear! intOREnet is not dead! I continue to work on it while I am ingame and is moving along nicely, but the progress isn't very reportable. Here's what I did today:
I've nearly finished the switch's address memory, and have decided that allowing people to change their addresses is pointless and would not only make the switch larger, but may also add some more delay. After that, I need to sync that up with some other components, add some minor stuff, add some stuff that has already been built, and something to detect if the switch is busy. Then, it will be pretty much done. The wires no longer have those bulky pistons, and there are only two wires(probably). I am switching to a more reliable way of loading the chunks on a when needed basis.
RE: intOREnet - slugdude - 07-15-2015
Due to the fact I have been banned for the duration of summer holidays for pinging Pablo a few times, intOREnet will have to be postponed indefinitely. Once school starts again in September I don't know if I will have enough time for the project. I might yet, but I doubt it, although I may have a teeny bit of time in weekends and half-terms. After that, I guess it'll be Christmas time. As a 'completion' date (although intOREnet can continue expanding) due to the circumstances, I'd estimate December-January time. To sum up, it's going to be a long fucking time until it's operational.
Edit: I just had an idea, if someone made a schematic of my plot and sent it to me, then I could continue the work on my machine in single player over the holidays.
RE: intOREnet - GISED_Link - 07-16-2015
You can work with people here... Like how the IPv4 was created. I'm sure there are a lot of people wich are full ready to contribute for the project. In my opinion the project is so big that you have to collaborate (otherwise the project will never have an acceptable release date).
Anyway. We are still waiting for some datasheet of your project
RE: intOREnet - Apuly - 07-16-2015
I'm pretty sure he hasn't made any data sheets.
RE: intOREnet - slugdude - 07-16-2015
(07-16-2015, 08:20 PM)GISED_Link Wrote: You can work with people here... Like how the IPv4 was created. I'm sure there are a lot of people wich are full ready to contribute for the project. In my opinion the project is so big that you have to collaborate (otherwise the project will never have an acceptable release date).
Anyway. We are still waiting for some datasheet of your project
Since I'm banned I'd see it difficult to collaborate with someone.
I'm not really sure how to explain it, but only one layer 1 protocol will be supported. I'll see if I can give you a more detailed explanation at a later date.
Edit: Actually I'm pretty sure only one layer 3 and 2 protocol will be supported, but I have little idea what this actually means.
RE: intOREnet - Apuly - 07-17-2015
Layer 3 is a network,
Layer 2 is comminucation between networks;
in layman's terms
RE: intOREnet - slugdude - 07-25-2015
Well, here is as I understand:
Two redstone wires will connect a switch to another switch, one each way. Each switch has a maximum of four connection to neighboring switches. When a packet arrives, the provided address is 'translated' to a 2 bit number which codes for which of it's four connections the original packet should be sent.
This process is repeated over and over until the packet reaches it's intended destination.
Each device (but not switches!) connected to intOREnet receives a universal 8 bit address.
This consists of two parts
The first 6 bits is the address of the 'hub' it is connected to. A hub is like a switch, but altered slightly so that it works with local networks.
The last 2 bits is which physical port on the 'hub' it is connected to. There are three ports on each hub (not four).
Each switch has a pile of memory that stores which of it's connections a packet must be sent for EACH 6 bit address it is not calculated on-the-fly as this would take a long time.
These 8-bit addresses are not unlike IP addresses, the main difference being these cannot be changed after assignment (although you can switch the physical port a dilevice is connected to thus changing the last two bits)
Never, ever, ever, ever send a packet to 00000000, because this is special and used for assignment.
Address 111111XX can be used similarly to 192.168.X.X, it is internal. The XX is the physical port the local device is connected to (00, 01 or 10). Since it is impossible for anything to have the address 11111111, it can be used like 127.0.0.1.
intOREnet does NOT guarantee the safe delivery of a packet, nor does it guarantee that a packet sent to the same address twice will take the same time to be delivered each time.
So, a packet sent from your devices must contain the following elements, in this order:
- A lead bit
- An 8 bit destination address as explained above.
- A lead bit (these make things easier when cutting up the serial packet.)
- An 8 bit source address (your address)
- Another lead bit
- 4 bits that will be a packet number. (Although strictly not necessary, this will allow clients to stitch data sent over multiple packets together should they be received in a different order)
- Another lead bit
- 4 bytes (yes, bytes) that is a blank canvas. This is your 'data'. It will not be altered or read by the switches themselves, and any structure or such can be placed within here. It does not have to fill all 4 bytes.
RE: intOREnet - fluffy406 - 07-25-2015
just go with RON
RE: intOREnet - Apuly - 07-25-2015
Here, have something that you're not supposed to have.
------------------------------------------------------------------------------------------------------------------------------------------------------------
IPv4 has been in use since 1983 when it was deployed on the Advanced Research Projects Agency Network (ARPANET), which was the precursor to the Internet. The Internet is largely based on IPv4, which is still the most widely-used network layer protocol.
An IPv4 packet has two parts:
- IP Header - Identifies the packet characteristics.
- Payload - Contains the Layer 4 segment information and the actual data.
Significant fields in the IPv4 header include:
- Version - Contains a 4-bit binary value identifying the IP packet version. For IPv4 packets, this field is always set to 0100.
- Differentiated Services (DS) - Formerly called the Type of Service (ToS) field, the DS field is an 8-bit field used to determine the priority of each packet. The first 6 bits identify the Differentiated Services Code Point (DSCP) value that is used by a quality of service (QoS) mechanism. The last 2 bits identify the explicit congestion notification (ECN) value that can be used to prevent dropped packets during times of network congestion.
- Time-to-Live (TTL) - Contains an 8-bit binary value that is used to limit the lifetime of a packet. It is specified in seconds but is commonly referred to as hop count. The packet sender sets the initial time-to-live (TTL) value and is decreased by one each time the packet is processed by a router, or hop. If the TTL field decrements to zero, the router discards the packet and sends an Internet Control Message Protocol (ICMP) Time Exceeded message to the source IP address. The traceroute command uses this field to identify the routers used between the source and destination.
- Protocol - This 8-bit binary value indicates the data payload type that the packet is carrying, which enables the network layer to pass the data to the appropriate upper-layer protocol. Common values include ICMP (1), TCP (6), and UDP (17).
- Source IP Address - Contains a 32-bit binary value that represents the source IP address of the packet.
- Destination IP Address - Contains a 32-bit binary value that represents the destination IP address of the packet.
![[Image: a0c3f7a95b.png]](http://puu.sh/jc8ux/a0c3f7a95b.png)
RE: intOREnet - Apuly - 07-25-2015
Also, this seems to have all the information you want/need: http://teachweb.milin.cc/datacommunicatie/network_layer.htm
RE: intOREnet - slugdude - 07-25-2015
IMPORTANT: PLEASE READ.
The layer two protocol is simply a lead bit, a two bit number that codes for which connection the switch should use, then the whole layer three packet, including header, inside it's 'data' section. However, you will NEVER have to deal with layer two, as it is only used within a switch, and is not actually sent between them. The difference between intOREnet and The Internet is that the layer three packet is interpreted at each switch, rather than only once. The hubs and switches all expect to receive the intOREnet layer 3 protocol. Only one will ever be supported, probably. It goes as follows:
![[Image: JfUtlh9.jpg]](http://i.imgur.com/JfUtlh9.jpg)
The '1's must always be 1s.
From bit 10 (d) onwards, this is actually irrelevant to the switches' operation. It is this protocol that MUST be used when a device sends a packet to it's hub, and this same, unaltered (mostly, see below) packet is received by the recipient at the other end.
When sending a packet, the source address does not need to be correct. The hub will make the source address correct for you, so it should be left as 00000000.
I hope this is a little clearer.
RE: intOREnet - fluffy406 - 07-27-2015
holy sheit 56bits
RE: intOREnet - slugdude - 07-27-2015
(07-27-2015, 07:24 AM)fluffy406 Wrote: holy sheit 56bits
I.e. 7 bytes. The actual data you send is just the last 4 bytes (32 bits) of that packet
If there is demand for either a larger or a smaller size of the 'data' section, please speak now.
RE: intOREnet - Legofreak - 07-27-2015
It doesnt really seem like you need sender data but i suppose if the receiver doesnt care, they can ignore it.
RE: intOREnet - slugdude - 07-27-2015
(07-27-2015, 09:21 PM)Legofreak Wrote: It doesnt really seem like you need sender data but i suppose if the receiver doesnt care, they can ignore it.
If there's an error, it can return an error report to sender (possibly)
RE: intOREnet - Legofreak - 07-27-2015
If thats the case, could there be a report of successful transfer as well?
or is that just the case when there's no error?
RE: intOREnet - Apuly - 07-27-2015
That's basically how tcp works
RE: intOREnet - LordDecapo - 07-30-2015
SOOOO MANY LEAD BITS!!!!! WTH
why so many lead bits? It doesn't change anything with the serial transmission, unless you just want to check packets for potential corruption
RE: intOREnet - slugdude - 07-30-2015
(07-30-2015, 04:39 PM)LordDecapo Wrote: SOOOO MANY LEAD BITS!!!!! WTH
why so many lead bits? It doesn't change anything with the serial transmission, unless you just want to check packets for potential corruption
1stly: it makes it easier with dealing with them in the switches, and 2ndly they may be used for ...other things... in the future. I'm not talking any more about that right now.
RE: intOREnet - slugdude - 07-31-2015
Some people have been complaining that intOREnet isn't making progress, however I can assure you that it is. Hastumer kidnly sent me a schematic of my plot so I can work on intOREnet while banned, and here's a component I finished building today:
![[Image: YKQxp7j.png]](http://i.imgur.com/YKQxp7j.png)
It stores everone's addresses, and which connection on the switch packets sent to that address should go through, and it handles some other minor things. it works all in serial, it's inputs and outputs are serial. also it looks like a flattened 'X' which is cool (I plan on putting things in the spaces in the sides). That picture is from around the 'back' because the front is more ugly.
So yes, intOREnet is moving forwards.
RE: intOREnet - LordDecapo - 07-31-2015
Does this store the entire address of people? Or just a part of it?
Cause I just had the thought of splitting up addresses into geographical regions. So you would only have to keep a single small memory segment saying which addresses are local, and the device then just has to read route it based on if the location referencedata is N,S,E,W of the switch.
Could speed things up a bit and shrink the switches
RE: intOREnet - Chibill - 07-31-2015
I like lords idea. It's simpler
RE: intOREnet - slugdude - 07-31-2015
(07-31-2015, 01:16 PM)LordDecapo Wrote: Does this store the entire address of people? Or just a part of it?
Cause I just had the thought of splitting up addresses into geographical regions. So you would only have to keep a single small memory segment saying which addresses are local, and the device then just has to read route it based on if the location referencedata is N,S,E,W of the switch.
Could speed things up a bit and shrink the switches
I did have a similar idea already but decided against it, but I can't remember why. Besides, it doesn''t look like it's going to be *that* big. Since things have already been built around the address system I described, changing it at this point would probably be extra unnecessary effort. The memory will be about half the size of the total switch. the hubs will be even smaller since all addresses except local ones should be routed to the switch it is connected to, thus there is no need for the memory and it's associated parts.
RE: intOREnet - Legofreak - 08-01-2015
Yap7 claimed the plot directly south of me... I'm kind of pissed because i was trying to get decapo to let me claim it just the other day.
Hopefully yap7 will allow lines through his plot or want to be a part of it.
RE: intOREnet - slugdude - 08-03-2015
(08-01-2015, 09:52 PM)Legofreak Wrote: Yap7 claimed the plot directly south of me... I'm kind of pissed because i was trying to get decapo to let me claim it just the other day.
Hopefully yap7 will allow lines through his plot or want to be a part of it.
I asked him to claim there so you could be connected. If you still need another plot there is one to the west of you.
RE: intOREnet - Legofreak - 08-03-2015
I didnt realize you asked him. I don't really need a new plot. Decapo denied because my plot isnt that filled up.
BTW, I'm glad to be in on the project now.
RE: intOREnet - LordDecapo - 08-03-2015
I just said, make a good argument to get a new plot (like say a new project is going to be massive and you need the space) if you need all the space for a project thats fine lol
RE: intOREnet - Legofreak - 08-03-2015
I was going to but I was procrastinating. I figured that it wouldn't get auto claimed for a while since I was so far out. Yap claiming that plot is just as good.
RE: intOREnet - IPositron - 08-05-2015
Omg dats genius
RE: intOREnet - TSO - 09-03-2015
SO... let's say I want to send something to LD from my nonexistant plot. To make it simple, I'll say that LD is a straight line to the west of me. I'll say the hub under me is hub 0, the one to my north is hub 1, the one to my west is hub 2. Okay, in order to get from me to LD, let's say it has to go through a minimum of 5 hubs. How does hub 0 know that the next hub it needs to get to is hub 2? Does it have a large table saying which of the other 62 connections are on which of the 4 output ports it has? If hub 2 is busy, and my hub decides to reroute through the north hub (hub 1), how does it know that by sending hub 1 my data, it will end up at LD's plot. When the data gets to hub 1, if hub 1 says that the best way to get to LD's plot is through hub 0, what prevents it from being routed back to hub 0?
RE: intOREnet - Back_and_Black1 - 09-04-2015
He probably will use LPM (longest prefix match algorithm) it's whats used irl.
RE: intOREnet - TSO - 09-04-2015
*uses google* I see... I think... mayb... no, I have no idea how that works.
RE: intOREnet - slugdude - 11-05-2015
(09-04-2015, 01:57 AM)Back_and_Black1 Wrote: He probably will use LPM (longest prefix match algorithm) it's whats used irl.
LPM is only used when the subnets have a varying prefix length. In intOREnet, all the subnet's prefixes will be 6 bits long. This makes the hardware sooooo much easier. Also I have made a few alterations to the protocol to support larger subnets and I will post it when done.
As for the actual hardware itself, little bits of progress have been made recently and I *AM* still working on this.
(09-03-2015, 10:12 PM)TSO Wrote: SO... let's say I want to send something to LD from my nonexistant plot. To make it simple, I'll say that LD is a straight line to the west of me. I'll say the hub under me is hub 0, the one to my north is hub 1, the one to my west is hub 2. Okay, in order to get from me to LD, let's say it has to go through a minimum of 5 hubs. How does hub 0 know that the next hub it needs to get to is hub 2? Does it have a large table saying which of the other 62 connections are on which of the 4 output ports it has? If hub 2 is busy, and my hub decides to reroute through the north hub (hub 1), how does it know that by sending hub 1 my data, it will end up at LD's plot. When the data gets to hub 1, if hub 1 says that the best way to get to LD's plot is through hub 0, what prevents it from being routed back to hub 0?
1. Hub 0 has a table telling it what direction to send packets depending on the subnet they address, so essentially yes
2. Due to the limitations of redstone, no re-routing can be done; because by the time hub 0 hears about hub 2 being busy, it won't be busy anymore because redstone is slow af. That said, some in-switch re-routing maaayyy be possible. The majority of packets received by the switches will probably be in straight lines, so if it receives another packet whilst still dealing with one, it could just send it straight on in blind hope. If it can't go that way, it will just be sent back, in which time the first switch would be free again. This may offer a slight advantage over just buffering the packets since if straight on is correct, then it would be faster.
That is a possibility but I haven't decided yet.
RE: intOREnet - Halflife390 - 11-05-2015
When will construction start! Iv been waiting for ages now. I know I haven't been on the server much lately due to other projects but I will return properly to work on this and other things.
RE: intOREnet - slugdude - 11-05-2015
(11-05-2015, 10:56 PM)Halflife390 Wrote: When will construction start! Iv been waiting for ages now. I know I haven't been on the server much lately due to other projects but I will return properly to work on this and other things.
That, I cannot answer. It'll take as long as it takes.
RE: intOREnet - anatevka - 11-06-2015
Wow. As only a moderately experienced redstonist, this is mindblowing. I'm still only in the student world, but I would love to be connected when I advance. Hopefully I'd be able to learn a lot from it
RE: intOREnet - slugdude - 11-06-2015
(11-06-2015, 08:34 AM)anatevka Wrote: Wow. As only a moderately experienced redstonist, this is mindblowing. I'm still only in the student world, but I would love to be connected when I advance. Hopefully I'd be able to learn a lot from it
In terms of the build server, the hardware isn't very impressive, other builders have built way more complex things.
RE: intOREnet - Magic :^) - 11-06-2015
slug what about having a packet buffer at each switch? That's what I was thinking about doing with a small scale network i'm kind of working on.
basically the way i -might- be doing it, is each switch can hold a packet and store it there while it waits for the next switch to be idle.
it might be a little slower, but redstone is slow af anyways
edit: ah but in my case all this hub/switch stuff would just be 1 routing 'node'
RE: intOREnet - slugdude - 11-08-2015
(11-06-2015, 12:54 PM)MagicalGentleman Wrote: slug what about having a packet buffer at each switch? That's what I was thinking about doing with a small scale network i'm kind of working on.
basically the way i -might- be doing it, is each switch can hold a packet and store it there while it waits for the next switch to be idle.
it might be a little slower, but redstone is slow af anyways
edit: ah but in my case all this hub/switch stuff would just be 1 routing 'node'
I considered that, but my switches are slow af. And buffers can overflow, and I don't want that.