+- 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)
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.