|
|
Post by Amelorate on Sept 24, 2014 22:39:26 GMT
So I've rewritten this about 5 times, and instead of rephrasing this over and over getting nothing over I'm just going to write this and see how it turns out. If you don't understand something I will ask and I will answer.
Basically everything uses packets to communicate with each other. A packet is basically a small message from one machine to another. They work in a Key : Content form. The key describes the content. Most packets should be able so you can sorta guess what they do. You should be able to sniff them and send raw packets. I'll explain this later in the post.
An example of a packet would be:
address_1 : 1234567890abcdef An address is always 16 characters and can have 0-9 and a-f.
address_2 : 2134567890abcdef You can include multiple address keys to send it to multiple things. This would be the message logging server.
send_address : 3124567890abcdef The sender of the packet; you in this case. You should be able to modify this string only with modified equipment.
type : text_message type is basically the protocol used for the packet.
message : "Hey bill how how have you been?" type specific keys start at this line.
sender_name : "Jhon John"
Sniffers should give you all the packets send as they are being sent out. If PDAs will be added, sniffers should be part of a cartridge.
Senders should allow you to create your own packets and send them out. Possibly you should be able to have different tiers of antennas. For example you would have the built in one in a PDA which would cover a mid sized station, while you could have a mounted antenna that can send messages to other stations. Also possibly a repeater antenna which would take all messages it sniffs and sends it again.
If files are ever implemented I also have an idea for how they can be easily sent.
|
|
|
|
Post by Nullbear on Sept 25, 2014 2:32:46 GMT
Great! Can you think of any physical electronic components that would be needed for wireless transmission in pda's and/or for these antennas etc?
Or are you suggesting that the several tiers of antennas could be the components in themselves for recieving packets?
I'm assuming this is relevant to the CT department?
|
|
|
|
Post by Amelorate on Sept 25, 2014 17:54:03 GMT
> Great! Can you think of any physical electronic components that would be needed for wireless transmission in pda's and/or for these antennas etc?
Possibly just an antenna would be needed for a PDA to send packets, since I'd assume they'd already have a processor to build the packets. For stand-alone antennas they would probably need a processor for building the packets and a bigger antenna to send/receive packets.
> Or are you suggesting that the several tiers of antennas could be the components in themselves for receiving packets?
I don't quite get what you mean.
> I'm assuming this is relevant to the CT department?
Yes.
Also I forgot to say that these are based off the little known or understood packet system on goonstation.
I'm also in the mood to suggest some more protocols for things. I guess I'm just doing airlocks for now.
door_debug when debug mode is enabled/disabled.
address_1 : null //null is also a valid content for address_#. Basically it sends it to everybody.
send_address : 3124567890abcdef //Same as before.
type : door_debug.toggled //Doors would need a wire cut or pulsed in order for this to work.
debug_text : "Debug mode toggled." //Sent when debug mode is enabled/disabled.
door_debug controls.
address_1 : [addr 1] //[addr #] is now my go to for an address.
send_address : [addr 2]
type : door_debug
command : open, close, lock, unlock, noaccess, access, disable// lock and unlock bolt and unbolt doors. noaccess and access disable and reenable if the door checks if you have access to the door on your ID, disable
//disables debug mode remotely.
//Also contents separated by commas are different correct entries.
door_reg access check with a ID server.
address_1 : [addr 3] //[addr 3] is the ID server. The ID server contains a list of all the ID keys and what access is assigned to them, logging who opens what door. A door keeps the address of the server in
//memory, so you cant easly impersonate an ID server
send_address : [addr 4] //[addr 4] is the door's address.
type : door_reg.access.check //Periods are used to separate subtypes if one type has multiple functions.
id_key : [idkey] //[idkey] is the ID's key assigned to it. An ID key is 16 characters 0-9 and a-f.
door_reg access check response.
address_1 : [addr 4]
send_address : [addr 3]
type : door_reg.access.response
status : accept, deny //accept opens the door if the ID is allowed in, deny displays the red light at the top is the ID isnt allowed in.
|
|
|
|
Post by Nullbear on Sept 25, 2014 19:52:09 GMT
This is great!
Now I'll let you know ahead of time for this, But there will no longer be any specific boards, like airlock electronics. Those will be made by the relevant department (CT or EM). This means you could have different door setups, Which are set up to use a specific ID key only, (for dorms, lets say.) Or well, any number of things. If you wanna go crazy you can set up a door that only opens when cake is nearby fcs.
I'll be using a lot of this in the design of CT, Some things will probably change a bit, but for the most part, same. I'll probably make this idea the default/standard airlocks electronics until folks decide to make their own.
A neat system i can see being implemented by this, Is a keycard swipe door, that accepts as normal, But logs the access to the server to make a record of who used what door when, etc. You could even add a camera to it so it snaps a photo for you.
|
|
|
|
Post by Amelorate on Sept 26, 2014 0:09:08 GMT
Since the new PDAs will need files for stuff, mostly news feeds, here I go.
file_send. This is more just to explain the file compression system.
address_1 : [addr 1] //address of the device being sent the file.
send_address : [addr 2] //address of device sending file.
type : file_send
file_key : [filekey 1] //Now this is a bit hard to explain, basically this would be an address of the file, but the address itself contains the file, basically it it compressed to the absolute limit. 16 char 0-9 a-f
file_name : "blah" //The name of the file, simple enough.
file_format : "txt" //The format of the file.
news_get
address_1 : [addr 3] //Server containing all the news.
send_address : [addr 4] //PDA requesting the news.
type : news_get
news_channel : "News" //What channel to download the news from.
news_get.send
address_1 : [addr 4] //PDA
send_address : [addr 3] //News Server
type : news_get.send
file_key : [filekey 2] //The file doesn't need a name, since its more of an extended packet than an actual file. This file contains the contents of the channel by the way.
|
|
