+- 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: RDTP: A IntOREnet FTP-like protocol! (/thread-10140.html)
RDTP: A IntOREnet FTP-like protocol! - TheRedCrafter344 - 06-23-2016
So, as I believe IntOREnet is (probably) going to come online in less than half a year (I hope), I decided I should come up with a protocol that allows us to tranfer data upon request!
The whole idea about RDTP(Requested Data Transfer Protocol) is that clients can send requests to a file server, and the file server would receive the request and send the data to the client. A request takes 23 out of the 32 bits IntOREnet packets have for data. The format is:
==MAIN PACKET FORMAT==
<Req. ID (3-bit)> <Address (12-bit)> <Data (8-bit)>
==ADDRESS TYPES==
An RDTP server can have "private", "public" and "protected" addresses. Private addresses can only be accessed by a specific client and public addresses can be accessed by anyone. Protected addresses are addresses that noone can claim(take them as their own).
==MAIN PACKET ANALYSIS==
The Req. ID is a 3-bit Identification Number used to transmit the request type.
Valid Req. IDs:
000: Read Public Address.
001: Write to Public Address.
010: Read Private Address.
011: Write to Private Address.
100: Claim Address.
101: Release Address.
110: Protect Address.
111: Ping.
The 12-bit Address area specifies which address to read, write, claim, release, protect, etc. As it is 12-bit, an RDTP data server can have up to 4.096 accessible 8-bit addresses!!!
The 8-bit Data area is used for write requests, it is the data written into the address.
==SERVER RESPONSE==
The server's response to a request differs depending on the request.
If the server is requested to read a public address, it simply returns the data in the address (DATA0000...).
If the server is requested to write to a public address, it returns 0000...0000.
If the server is requested to read a private address, it checks whether the client requesting the data is the "owner" of this address, using a proccess described below. If it is, it returns the data in the address(DATA0000...). If it is not it returns 0000...0001.
If the server is requested to write to a private address, it checks whether the client sending the data is the "owner" of this address, using a proccess described below. If it is, it returns 0000...0000. If it is not, it returns 0000...0001.
If the server is requested to claim an address, unless the address is protected or private, in which case it responds with 0000...0000, the server sets the address' state to private, the owner of the address is set to the client who sent the request and the server responds with 0000...0001.
If the server is requested to release an address, unless it is a public address, in which case it responds with 0000...0000, it checks whether the client sending the request is the owner of this address and if it is, the address' state is set to public and the server responds with 0000...0001. If it is not, the server responds with 0000...0010.
If the server is requested to protect an address, unless the address is protected or private, in which case it responds with 0000...0000, the server sets the address' state to protected, the owner of the address is set to the client who sent the request and the server responds with 0000...0001.
If the server is requested to ping, it returns 0000...0000.
==CLIENT AUTHENTICATION==
A client can be authenticated in only few steps!
1. Server stores the request packet the client sent.
2. Server generates and stores a random number and sends it to the client.
3. Client receives the random number and XOR's it with its iOn address to produce the Signature, which it sends to the server.
4. Server receives the Signature and XOR's it with the iOn address it stored at step 1, then it checks whether the number it generated is the same as the number it generated at step 2.
If it is, the client is real and authenticated! If it is not the same, the client is fake. DUM DUM DUUUMMMM!
======================================================================
If you have any extra suggestions, tell me in the comments!
RE: RDTP: A IntOREnet FTP-like protocol! - slugdude - 06-24-2016
Xred, I suggest you don't do more work on this until I'm available to help, I'm probably going to create a system within the intOREnet packets that identifies each protocol so a device knows what it is receiving. I haven't thought too much about it yet because there are more important things to worry about.
RE: RDTP: A IntOREnet FTP-like protocol! - TheRedCrafter344 - 06-24-2016
Bump and Update!
RE: RDTP: A IntOREnet FTP-like protocol! - VoltzLive - 07-07-2016
Ok like.... I know it's minecraft and all
but you shouldn't send anything remotely similar to the password through plaintext.
RE: RDTP: A IntOREnet FTP-like protocol! - Iceglade - 07-07-2016
(07-07-2016, 10:54 AM)VoltzLive Wrote: Ok like.... I know it's minecraft and all
but you shouldn't send anything remotely similar to the password through plaintext.
I don't think hacking should really be a genuine concern with a network this simple. Make it work first, then add security.
RE: RDTP: A IntOREnet FTP-like protocol! - TheRedCrafter344 - 07-18-2016
Bump and HUGE UPDATE!
RE: RDTP: A IntOREnet FTP-like protocol! - Matthew - 07-20-2016
eh... this is like a weird over complicated version of WNS...