Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Search the Community

Showing results for tags 'network'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL








Fediverse ID



Found 22 results

  1. Heyo! 1M here! Soo...I made a block of raid and put drives in it, and promptly realized that I could not find raid documentation, nor could I find how to use it. My question is, how do I a.) access the raid. b.) put data onto the raid. Any help will be appreciated, as I am on my first use of this mod, and so far it looks amazing! Thank you in advance! 1M out!
  2. In OpenComputers we currently have a simple highly abstracted networking model. We do have ports, thankfully, but besides that the model is highly abstracted and thusly underpowered. The first suggestion, is remove the abstraction on network communication in the first place. Allow this to be configured in the mod preferences file, but have it enabled by default. By default, there is no “hardware addresses”. A cable is just that, a cable. The only API by the mod is “broadcast and receive”. In the OS provided by the game by default could still have the same API as now. The different is it’d behave like broadcast, with packets being what are broadcasted. The new network card API (excluding any OS-level abstraction would look like this: - card:up() - card:down() - card:listen() - card:transmit(raw) Already, we now have a lot of extra things. It encourages crafting an encryption card (or whatever it’s called) because users can now snoop and preform MITM attacks on these packets, since there is no game mechanic (provides by the mod itself) preventing posing as somebody else. That also means you can simulate multiple networks cards in software while crafting only one. Second, something that kinda complements the idea of the first suggestion. Cable bandwidth limits. Just like normal cables, there is a limit to the amount of data we can cram into a single cable. Since the last suggestion removed the magic of hardware addresses, we actually need to listen to packets on the cable. We can only process so many packets so often. Now, us developers have an actual NEED to work on more complex softwares. We need to design things like intelligent multiplexing algorithms and routing softwares to efficiently receive, decode, process, bundle, re-encode, and transmit packets. There will also now be tiered network cards, that change things like the maximum number of packets a second the card can receive and transmit. It could also limit what kinds of cables the system can connect to. For example, you might need a tier four to connect to fibreglass. Keeping on the same note, Radio Frequencies. Just like cables, we can only send so much data through the air at once. One way we allow for more people talking wirelessly, besides just having everybody wait their turn in a long que to talk, is Frequency Multiplexing (FM). This also adds a new unique challenge, but powerful tool, to busy areas. You can allow a lot of people to talk at once using multiple frequencies, but you need to develop systems to send data to users on the right frequency to have them actually receive it. Radio Frequencies would have different reasons to use it. Higher frequencies can transmit farther, but they use more power and they can be affected by things like weather (If I understand correctly some RF wavelengths can experience interference due to the size of the droplets). Lower frequencies would use less energy, but have lower range, but less susceptible to interference from things like weather (however, if memory serves right, lower frequencies are more noisy; translates in-game to possibly more failed packets and corruption). In the game, tiered wireless cards have been added. The higher tiers have the capability for wider bandwidth (meaning the range of RFs the card can use), multiple antennas (allowing use of multiple frequencies at once), and higher bandwidth (packets/second it can receive and transmit). To craft these, one good way could be like how you setup server racks. You can open a GUI where there are slots. You need better processor for higher throughput (packets/second) and higher memory for higher throughout volume capacity. All my suggestion make the game more difficult, sure. That’s why I use it over ComputerCraft. I like having my computers be complex and expensive, they should be! They’re freaking computers. This adds the ability to design a lot of new things, and new challenges. However, they won’t really effect new players. On your small one or Teo computer network running the default OS, everything will work perfectly fine. Only large-scale complex systems have these issues.
  3. Hello. So, I'm making an (in-game) monetary transaction system and for that I need encryption. Documentation on the data card is extremely poor (no examples). Here's what I have so far: Note! The key transfer has already been done. --Machine #A local pubKeyA, privKeyA = data.generateKeyPair() local shKeyA = data.ecdh(privKeyA, pubKeyB) local message = "Hello?" ---[What happens in here to encrypt data?] modem.send(encryptedData) --just placeHolder --Machine #B local pubKeyB, privKeyB = data.generateKeyPair() local shKeyB = data.ecdh(privKeyB, pubKeyA) local message=event.pull() --just placeholder ---[What happens in here to decrypt data?] print(decryptedData) Any and all help would be appreciated.
  4. This project is no longer being maintained, and has not been for a while. I may eventually make a new version, but I would first like to make an addon for OpenComputers to allow long-range wireless signals so that you can connect globally to a server. The OpenNet: Internet like simulation in Minecraft REQUIRES WIRELESS NETWORK CARD Not tested with wired network card This is very WIP, but it still works well for what it does. The OpenNet requires one computer to be running at all times as DNS. This allows for DNS lookup and not having to type things like "af4c71b5-c3be-4da1-b595-4d0afd40359d" to go to a page. It also requires a computer to be running all the time for each web server. The client and web server need to know the DNS server's address, so if this is implemented on a server, it is best to have one central DNS server. Downloads: DNS Server pastebin get 1pp05ryR opennet-dns.lua OpenNet Web Server (configure dns network card address inside file) pastebin get PRTmhN1a opennet-server.lua OpenNet Web Browser (configure dns network card address inside file) pastebin get jMNz5Bej OpenNet.lua Screenshots: OpenNet DNS OpenNet Server: OpenNet Client: ONML: ONML (OpenNet Markup Language) is a simple web page language (not many features yet) that allows you to change the background and foreground color of the site. The colors are cleared after displaying them. To change the color of text, prefix the color with one of these colors (use three letter name): "RED", "ORA"(orange), "YEL"(yellow),"GRE"(green),"BLU"(blue),"PUR"(purple),"WHI"(white),"BLA"(black) To change the color of the background, type "BACK <COLOR NAME>". <COLOR NAME> is one of the colors shown above (use three letter name) Example ONML file: BACK RED WHI The OpenNet: Internet for OpenComputers YEL The OpenNet is an open source wireless communication system made with Lua for OpenComputers. WHI It includes a 8 color (red "RED", orange "ORA", yellow "YEL", green "GRE", blue "BLU", purple "PUR", white "WHI". black "BLA") foreground and background system, along with things similar to DNS Demonstration of the shown ONML file: Roadmap (in no order): Real Internet ONML ONML links/interaction More pages than just the main page
  5. When using the internet component or internet API I could not find a reliable way to detect a broken socket to an internet adress. Once the connection is broken by the external endpoint, the broken socket can only be detected by writing to the socket, not by reading. This makes writing a good program very difficult as it would be impractical to send a ping every second just to detect if the socket is still alive. Is there any possibility I did not see? Or is none implemented?
  6. Simple (forward) DNS with minimal Setup Server-client architectur. Every client register his address automatically at server. Server hold a table of registred clients. Clients can send requests to get a address of a registred client. Its possible to setup multiple dns Server with own binded hosts in same network. If host not binded them try to find antother random dns server automatically. startup order of hosts and server not important. Server/Client support some arguments at runtime dnsserver status / dnsclient status dnsserver restart / dnsclient restart dnsserver start / dnsclient start / dnsserver stop / dnsclient stop dnsserver print (printing all entrys) dnsserver drop (delete all entrys) Example for usind Lib local dns=require("dns") local networkaddress=dns.ns("Computername") -- with local cached entrys to reduce network traffic --or local networkaddress=dns.ns("Computername", true) -- witout local cache. forced request on server more secure Important editable Files /etc/dns.cfg Installationfiles (u need a internet card and oppm) pastebin get sBWERkg3 server.lua pastebin get sThmq5sr client.lua
  7. Using this program, you can host an array filesystem over a network. Set up is as simple as installing an autorun.lua script on the computer or server that hosts the ServerFS filesystem, and installing a boot script on the clients that will access the ServerFS filesystem. How it works: The "Host", the computer or server hosting the ServerFS fileserver, runs an autorun script which will allocate all non-primary filesystem components to a single virtual "ServerFS" component. It then receives messages over the network and when a message is received relating to the ServerFS the Host will then respond to the sender with a message with data related to the method it was trying to call. A "Client", a computer or server connecting to the ServerFS Host, has a boot script installed which runs at startup and sets up a virtual component which functions like a normal filesystem component. Calling one of the virtual component's methods will cause the Client to send messages to the Host computer and wait for the Host to respond. The boot script also automatically mounts the virtual filesystem component to the "srv" directory. Requirements: The component must have a type of "modem" or "tunnel" in the computer or server. Network cards and Wireless Network cards have a type of "modem", while Linked cards have a type of "tunnel". Therefore, you can use a Network card, Wireless Network card, or Linked card to connect to the Host computer. The other components required are the filesystems you want in the Host's RAID array. You must also have at least one filesystem attached to the Host computer. How to set up ServerFS: The "Host", the computer or server hosting the ServerFS fileserver. Step 1: Install a modem or tunnel component (a Network card or Linked card will work for this, as each card acts as a modem or tunnel component respectively) to the Host computer or server, then install any filesystem components you want in the array. Step 2: Get the autorun.lua script on to the Host. If the Host has an internet component installed execute "pastebin get cg1ieKUi /autorun.lua" and the required autorun script will be downloaded, or if you are the server host get the script at http://www.pastebin.com/raw/cg1ieKUi and add the script to the root of the filesystem that hosts the operating system. Step 3: Run the autorun.lua script. The autorun script will allocate all non-primary filesystem components to a virtual filesystem array, and then will host the ServerFS functionality. The "Clients", or computers connecting to the ServerFS fileserver served by the Host. Step 1: Install a modem or tunnel component to the Client (a Network card, Wireless network card, or Linked card will work), then connect the Client to the Host. Do not connect it to the Host directly if a large amount of components are inserted to the Host, as this can cause the Client to stop and show a "Too many components connected" error. Step 2: Install the boot script to the Client's boot filesystem. If the Client has an internet component installed execute "pastebin get HAgcbg41 /boot/98_serverfilesystem.lua", or if you are the server host get the script at http://www.pastebin.com/raw/HAgcbg41 and add the script to the path of "/boot/98_serverfilesystem.lua" on the filesystem that hosts the operating system. Step 3: Reboot the computer. On startup a "srv" directory will be mounted. Additional Information: Please note that accessing functions of the server filesystem is noticeably slower than accessing the other filesystems on your network because the Host has to receive the request of the client from the network (which adds a delay that can be reduced by adding a CPU or APU to the relay if there is any), then process the request, and then send the processed information to the client. Don't expect it to be as fast as accessing functions of a filesystem attached to your computer. If the network has relays connected, if too many requests are sent at in to short a timespan this can cause requests to be dropped by the relay and cause problems. You should shut down the Host computer before adding or removing filesystems from or to the Host computer, as not doing so can cause issues where the server will attempt to access filesystems that are not attached to the computer. For anyone that says that the files you create from the client are blank, this issue is caused by a change of the filesystem handling in an update to the OpenComputer mod, where file handles are not numbers anymore. I already made an updated version which is compatible with the updated handling of file handles and fixes the error by using numbers for file handle identification. The updated version to fix the issue has now been published. Update the script on the Host, then test to see if that fixed your issue. If not then report the issue you are having (post the issue again and that you updated the script if the same issue occurs). Download: The hosting autorun.lua script is at http://www.pastebin.com/cg1ieKUi The 98_serverfilesystem.lua script to add in the boot directory of your clients is at http://pastebin.com/HAgcbg41
  8. The following document is still a DRAFT and a subject to change, though protocol and assigned numbers should not change. 1. Purpose ON2 - OCNet L2 protocol - is a very simple standard is aimed at advanced network stacks. It provides protocol tagging and optional vlan separation for devices that support it. 2. Protocol ON2 utilizes the fact that OpenComputers network message can have multiple parameters. When a message(data frame) is sent using ON2 layer, the implementation sets first data parameter to protocol number and passes the data via second data argument. Port number(if supported by device) can be used as VLAN tag allowing network separation. Default port number(vlan) is 1 Here is an example modem call for sending data frame with protocol 0x46 (IP frame): component.invoke(modem, "send", dest, vlan, 0x46, ip_data) 3. Implementation recommendations Each network stack implementation should default to listening and sending on port 1. If packet of with unknown protocol number is received is should be silently dropped. Implementations should pass local/remote address and interface information(modem ID, vlan or interface object) to higher layers. 4. Protocol numbers: Protocols are identified by numbers assigned in table below. |-------------------------------------------------------------| | PROTOCOL NUMBER | PROTOCOL NAME | DEFINING STANDARD | |-----------------X--------------------X----------------------| | 0x0C | OC HOST DISCOVERY | OETF #9 | |-----------------X--------------------X----------------------| | 0x46 | IPv4 or IPv6 Frame | RFC791 and RFC2460 | |-----------------X--------------------X----------------------| | 0xCF | OHCP CONFIG PROTO | OETF #10 | |-----------------X--------------------X----------------------| | 0x1000 | MultICE | ??? | |-----------------X--------------------X----------------------| | Above 0xFFFF | User defined | N/A | |-------------------------------------------------------------| You can apply for assigning protocol number by a post in this thread.
  9. OETF #10 - OHCP - simple DHCP/BOOTP like protocol for host auto configuration. 1. Protocol This is specification for a binary data frame(a Lua string), sent over OETF #7 protocol with protocol number 0xCF. BYTE 0 | BYTE 1 | DATA | BROADCAST --------------------|--------------------------|----------------------------|----------- 0x00 - ADDR REQUEST | NOT SET | NOT SET | ALLOWED 0x01 - CLIENT RESP | 0x00 IPv4 address assign | IPv4+subnet byte (4b + 1b) | NO 0x01 - CLIENT RESP | 0x02 IPv4 gateway | Gateway IPv4 (4b) | NO 2. Protocol Flow When a new client is starting up, it SHOULD broadcast `ADDR REQUEST` once. In case of no response it may retry after at least 15 seconds. If server has free addresses in address pools it should respond with `CLIENT RESP` packets, setting the client up.
  10. 1. Purpose OETF #9 - OC Host Discovery Protocol is a host discovery protocol for local OC networks specified by OETF #7. 2.Protocol This is specification for a binary data frame(a Lua string), sent over OETF #7 protocol with protocol number 0x0C. All frames are allowed to be sent as a broadcast or as a direct message. Prefix byte | Action | Payload ------------|-------------------------------------|----------- 0x01 | Peer IPv4 Advertisement | 4 byte IPv4 0x02 | IPv4 Discovery request | Optional 4 byte IPv4 [reserved] | | 0x08 | Peer IPv6 Advertisement | 16 byte IPv6 0x09 | IPv6 Discovery request | Optional 16 byte IPv6 When a peer in a network receives a 'Discovery request', it MUST respond with a 'Peer Advertisement' massages with all addresses set on a given interface. When a peer is assigned an address is SHOULD broadcast a 'Peer Advertisement' message. Some implementations may choose to broadcast those is some set periods, if they choose to do so, it's recommended to set the interval to at least 60 seconds to not stress the network. Responses to 'Discovery request' frames SHOULD NOT be a broadcast messages. When there is no payload in 'Discovery request' frame, all addresses set on a given interface should be advertised. Implementations MAY choose to not implement filtering in 'Discovery request' frames, falling back to the no-payload behavior.
  11. net API - The most basic DNS system How this works: The DNS server constantly broadcasts out its information every 2 seconds on the specified port The client APIs have a function to search for the next DNS server (they wait for the above information) which then sets the table containing the information to net.foundServer Now the client APIs have the ability to call net.setDNS(net.foundServer.address) to lock to that DNS With that the client APIs can now register and delete their URLs on this DNS server Every other client who has that DNS server locked on too can look up your modem's address by calling net.resolve(url) [returns true/false and the message (either an error or the address)] Requirements: DNS server: A setup with color support (it logs stuff on the screen and uses colors for that too) Of course a wireless network card My multitasking API which should be saved as "oc_multitasking_api" At best: openOS (because it uses the keyboard and event api) Client: The api A wireless network card of course And maybe an idea on how you can make use of it At best: openOS (because it uses the event api) How to set it up: Build a server / computer for the DNS server (look at the requirements) Buld a computer for the client(s) (look at the requirements) Create a new program to use the API NOTE: At boot, the API doesn't have a DNS server registered, you NEED to register it using net.listenForDNS() or directly putting in an address local net = require("net") --This needs to be called for every program which uses the API, which is normal net.listenForDNS() --This wont stop until it gets a message from a DNS server net.setDNS(net.foundServer.address) --Set the locked DNS to the actual address of the found server Functions: listenForDNS() : Waits for a DNS server to broadcast it's information registerURL([STRING]): Registers an URL for your modem's address (Returns true/false with an (error-) message) removeURL([STRING]): Removes the given URL from the DNS if it's yours (Returns true/false with an (error-) message) setDNS([STRING]): Set the locked DNS' address to the given one getDNS(): Get the currently locked DNS' address (returns the address of the DNS server's modem) getPort(): Get the port which the API looks for messages from the DNS server setPort([NUMBER]): Set the port which the API looks for messages from the DNS server resolve([STRING]): Try to get the modem address of the given URL (Returns true/false with the address or an error message) getURL([STRING]): The reverse of the above function (Returns true/false with the URL or an error message) getAll(): Returns a table with every URL and the associated address on the DNS server (key = URL, value = address) Download: DNS server: Pastebin net API: Pastebin NOTE: The DNS server does currently not save the DNS list on reboot and it looks like it stops broadcasting when the computer stays on when closing the server / game.
  12. So uh, I don't have a name for it. I guess it's a little like a UUCP network... I'm open to suggestions Over the last few days, I've been in the car a lot. And these are like, 3 hour trips. I've decided to measure the amount of code I write in car trips. Anyway, this is what I've been working on. I haven't noticed any bugs, but there is no current functionailty beyond forwarding, there is no security the max message size is just under 8KiB, due to OC limitations (Configurable), and it's kinda loud because I needed debugging messages. Oh yeah, it requires a Computronics tape drive to serve as a buffer for messages. Okay, so here's the form of the packet: path,retPath,name,user,message path is the path of nodes to use, separated by !s, eg. 'derp!boom!bang' retPath is the path to return a message. It should be a reversed path, but if you wanted you could mess with it and fake the retPath name is the name of the message. Could probably be helpful in transferring large files to get around the 8k limit user is the user it's addressed to on the final destination. Could probably impliment a user for requesting information about a node. message is the actual contents of the message. The whole thing should be less than 8KiB due to the packet limits so we can't kill smaller computers If you want something to happen when it's addressed to a user on your system, modify recvMsg. At the moment, it can forward messages and that's it, I'm gonna work on more stuff soon. I suppose you could also have an inter-server network or a wormhole using the internet cards. Anyway, here's the code: http://pastebin.com/meECUXwn It's decently (sarcastically) commented. To set up a node you'll need to change the address (commented) Here's a name that just occured to me: Ticking Tile Entity. I left one of Asie's tapes playing with a broken audio file on it and it crashed my game with that error. Apparently the tape tried to stop at the wrong microsecond. That's all I know. Now... What did I forget?
  13. The following document is a DRAFT. Any information here may be revised at any time, and suggestions are more than welcome. Rev. #2017010401 (0.1.1) Abstract This draft defines the NNR (Network to Network Routing) protocol as part of the OCranet family of protocols. This document outlines how dynamic routing holds networks together in an NNR enabled OCranet network, how signalling is performed to control these networks, and the format of addressing used. This protocol is NOT the base protocol for OCranet networksand REQUIRES the support of specifications detailed in OETF #4; OCR (Ocranet Relay) protocol. Rationale The specifications detailed in OETF #4 only provide a means of cell forwarding for data networks and a robust topology. In the majority of cases it is not intended to be a stand-alone protocol. In a network of this type without any further support, only static routing can be achieved, requiring the manual configuration of connections along a path in a more permanent like manner. OETF #4 specifically and generously reserves a feature allowing us to control such a network beyond the boundries of its specification and is described in detail under section "Switches", sub-section "Services" in OETF #4. The specifications detailed in this document are built upon this feature, allowing a network to dynamically configure itself given little configuration by introducing 3 concepts called SIGNALLING, DYNAMIC ROUTING, and NODE ADDRESSING. Signalling Signalling is the concept of communicating with a network independent of other connections to receive information from, provide information to, or configure networks, usually in a pasive manner. with NNR, signalling becomes the heart of how an OCranet operates. All signalling in an NNR enabled network occurs on VPI 0, VCI 4. All signals are represented using 8 bit identifiers in a 1 byte header immediately following the VPI and VCI fields in an OCR cell. List of signal names and identifiers HELLO (0x01) Used by the active LOOP COORDINATOR to announce information about the network to newcomers. The information provided is as follows: (8 bits) The revision of the NNR protocol supported by the network (Currently 0). (128 bits) The Link Local address of the LOOP COORDINATOR (This provides the 16 bit Link Local prefix for local scope autoconfiguration)(48 bits) A 32 bit Network identifier and 16 bit Subnet identifier, if either is applicable (For global scope autoconfiguration) WHOIS (0x02) Sent by anyone to request if a particular address is in use. This can be an address of any type within the scope of the NNR addressing format [SEE BELOW]. If there is no response within 10 seconds of transmitting the WHOIS signal, then the address is considered up for grabs by the node which original sent the signal. The WHOIS signal is comprised as follows: (128 bits) The address being queried DEIFY (0x03) (Implementation currently optional) When no HELLO message has been received by the LOOP COORDINATOR for a given time, It is possible that the LOOP COORDINATOR has failed or disconnected for some reason. In this event, each switch with the same Link Local prefix count the entries in their routing tables for each virtual path, including their temporary cached entries and broadcasts a DEFIY signal on the loop. Though important for reliability, due to the complexities of this operation its implementation is currently optional. The DEIFY signal is comprised as follows: (128 bits) The link local address of the node they wish to become the new LOOP COORDINATOR INUSE (0x04) Broadcast message sent by a node witnessing a WHOIS broadcast with their Link Local address to inform the sender that the address is currently in use and active. The INUSE signal is comprised as follows: (128 bits) The address being queried in the WHOIS signal DIALOUT (0x05)(Forward recursive) unicast message sent to the LOOP COORDINATOR to request to build a circuit to the specified global scope address. The DIALOUT signal is comprised as follows (128 bits) The global scope address of the end node to reach (16 bits) A tag number passed back the LINE signal upon successful circuit construction informing the previous-hop / initiating node which connection is ready. This number can be anything, but should be unique within a short time frame at minimum. This number should be cached and changed at each hop as a security measure to prevent switches from becoming confused during circuit construction. (30 bytes) A host-dependent (Not covered in this document) data payload containing any information the end host needs to set up a connection. ACK (0x06) Unicast sent by any node acknowledging a signal from another node. This should be sent after any unicast message to prevent nodes from repeating themselves when signal reliability is necessary. The ACK signal is comprised as follows: (8 bits) The signal identifier being acknowledged. HUP (0x07) (Unidirectional/Multidirectional recursive) unicast message sent to the next-hop and/or previous-hop switch indicating to tear down / hang up the active circuit. This causes a recursive ripple effect that automatically tears down a connection. Any nodes in between that have not received the message should eventually time out and initiate an HUP signal themselves if applicable to fully dissassemble the circuit and prevent zombified links. If an HUP signal is not initiated at an endpoint node, then two HUP signals should be produced if applicable; One for the next-hop, and one for the previous hop. For security purposes, an HUP signal MUST ONLY be listened to if it arrives via the VPI & VCI pair it is associated with / forwards to. An HUP signal is comprised as follows: (8 bits) The Virtual Path Identifier in the direction of the teardown (16 bits) The Virtual Channel Identifier in the direction of the teardown LINE (0x08) (Reverse recursive) unicast message initiated from the end node providing all information the previous-hop needs to forward messages in a circuit to the next-hop toward the end node. The LINE signal is comprised as follows: (16 bits) The tag specified during the DIALOUT signal (16 bits) The VCI of the next-hop (8 bits) The VPI of the next-hop Addressing NNR uses a 128 bit address format that contains the following information: (16 bits) Address type (16 bits) Address parameters (32 bits) Network identifier (16 bits) Subnet identifier (48 bits) Host identifier A complete NNR address is represented in the following way: TTTT:PPPP:NNNNNNNN:SSSS:HHHHHHHHHHHH Where TTTT is the address type, PPPP is the address parameters, NNNNNNNN is the network identifier, SSSS is the subnet identifier, and HHHHHHHHHHHH is the host identifier. Address types Current, only two address types are supported. These are Link Local (0x0000), and Link Global (Address type 0x9001). Link Local addresses are unique within a loop and its next-door neighboring networks. The 16 bit parameters field in this case is called the "Local scope prefix" and provides a virtual barrier between networks on the same or adjacent loops. All nodes in the same local network share the same local scope prefix, but a switch bordering multiple networks may have more than one local scope prefix, and thus more than one link local address; One for local network group. Link local addresses are used solely for communicating within a local network group and can not be routed accross networks. A node with only a link local address has the added security of being globally invisible and unreachable without more complex routing infrastructure which is outside the scope of this document. Link Global addresses are unique for each network cluster (And MUST be unique within the entire OCranet scope). These addresses are used for communicating to nodes in neighboring or distant network loops. Shorthand formatting of addresses The subnet portion of global scope addresses is required to be present but may optionally used for routing [SEE SUBNETTING]. Likewise, the network AND subnet portions of a link local address are required but never used. For this reason, it is acceptable and RECOMMENDED to use the shorthand (double colon) operator when representing addresses for human readability. The double colon MUST only be used once in an address, and its position is dependent on the address type. A couple examples are provided below: The Link Local address 9001:0000:37f:0000:a8f35779fe4b can be shortened to this: 9001:0000:37f::a8f35779fe4b The Link Global address 0000:5f:00000000:0000:a8f35779fe4b can be shortened to this: 0000:5f::a8f35779fe4b Dynamic Routing In order for signals to operate, processes that fit in the category of dyanmic routing are necessary. These processes are as follows: New node joins a network loop Host NEWHOST is attached to a network loop. The procedure is as follows: NEWHOST waits for 20 seconds and listens for a HELLO signal or DEIFY signal. - If no signal is received, NEWHOST assigns itself a Local Scope prefix. This may be preconfigured or generated randomly. Use precaution when generating randomly to ensure that neighboring networks do not share the same prefix. It is much easier to just assign it manually when creating a new network loop for the first time. - If a HELLO signal is received, NEWHOST assigns itself the Local Scope Prefix of the LOOP COORDINATOR. - If a DEIFY signal is recieved, NEWHOST waits another 20 seconds and resumes from step 1. NEWHOST uses a UUID (It is RECOMMENDED to use the UUID of the OC network card in use if applicable) to generate a Link Local address using its Local Scope Prefix. NEWHOST sends a WHOIS containing the Link Local address it generated and awaits for an INUSE signal for 10 seconds. - If NEWHOST receives an INUSE signal with the Link Local address it generated, a new 48 bit host identifier must be generated. After this is done, resume to step 2. - If NEWHOST does not receive an INUSE signal with the Link Local address it generated within 10 seconds, it assigns itself that Link Local address. NEWHOST may optionally configure itself a Link Global address following steps 2 through 3 but instead using Link Global addressing. In the event that NEWHOST is a switch bordering another network and an existing LOOP COORDINATOR is available, NEWHOST sends a NEIGH signal containing a route to the network it binds to the LOOP COORDINATOR. This document may be a stub; It provides the majority of specifications for the NNR protocol but may be missing some specific features and will be updated within the near future.
  14. The following document is a DRAFT. Any information here may be revised at any time, and suggestions are more than welcome. Rev. #2017032401 (0.2.0) Abstract This draft defines the OCR (OCranet Relay) protocol as part of the OCranet family of protocols. This document outlines how OCR forms connections, how data is fowarded, and the structure of a data segment used in an OCR network. Rationale An agreement between computers in terms of how to communicate is important in any data network. In the past, there have been several attempts to build networks to transfer data bewteen machines, but it has been hard to come by a family of protocols that are unobtrusive, portable, passive, reliable, fast, versatile, easy to implement, and easy to maintain all at the same time. Meanwhile, in time, curiosity has brought up questions of inter-server communication; Data transfer between OpenComputers machines accross multiple Minecraft servers. It is the research on this subject that has brought attention to a new protocol that is capable of fulfilling all of these requirements. Thus, as a pun on ARPANet, the OCranet is born. OCranet Relay protocol (OCR for short) is responsible for gluing the OCranet together in hopes of forming a large scale network for all of us. Conventions This document follows all guidelines proposed in RFC 2119. Circuit switching, paths, and channels OCR networks form a circuit switched topology. This means that routing is predetermined for any given connection; Instead of determining the path of data for every segment, the path is determined when the connection is first initiated and BEFORE communication with the destination host begins. Unless a network failure occurs, any data part of a connection should always follow the same path to get to its destination until the connection is torn down. Virtual Paths OCR makes use of virtual paths which represent the physical or virtual next-hop destinations a host may reach. The wire connecting each computer face to face in a network is called a LOOP. There are two standard models for constructing an OCR network: internal routing, or network interconnection only. Using an internal routing model, OCR is used to route between each host on a network, while on the other hand a network interconnection only model uses OCR only for interconnecting each network, but not the hosts inside of them. A complex network can be built by arranging multiple loops and connecting them together by using one or more OCR switch(es) [DOCUMENTED BELOW]. Using an internal routing model, each host on a loop is identified by a Virtual Path Identifier (VPI). However, using a network interconnection only model, only each network has a particular VPI. This number is 8 bits, therefore there may be a total of 256 hosts on the same loop. When using OCR with an internal routing model, VPI 0 is RESERVED for speaking directly with the host. When using OCR with a network interconnection only model, VPI 0 should be reserved for speaking to that network (ex. a switch that governs that network). Virtual Channels Each connection from a host is represented by a single Virtual Channel Identifier (VCI). a Virtual Channel represents a connection within a Virtual Path. The Virtual Channel Identifier is 16 bit, therefore every host can simultaneously handle a maximum of (256 * 65536) = 16,777,216 connections at any time. Bear in mind that VPI 0 is reserved, so more likely your maximum sustainable connection limit will realistically be (255 * 65536) = 16,711,680 simultaneous connections. Switches To separate multiple loops, a switch is deployed and is responsible for forwarding in that direction. switches are REQUIRED at minimum to be responsible for keeping track of VPI and VCI pairs as well as forwarding data along these Virtual Paths via their Virtual Channels. In order for a switch to perform its job, additional features are RECOMMENDED. These features should control the use of Virtual Path and Virtual Channel propagation. One such example of a feature is a dynamic ROUTING PROTOCOL which might be responsible for performing an address or telephone number lookup and building a chain of Virtual Path and Virtual Channel pairs across an OCranet network. The complete concept of OCR routing protocols intended to be extensible and separate from OCR, and therefore is outside the scope of this document. Forwarding The process of re-transmitting a data segment to the next-hop switch or computer is called forwarding. The Virtual Path Identifier and Virtual Channel Identifier always indicates the VPI and VCI pair that matches on the next-hop switch. This means that if the computer you are speaking to is on VPI 3, VCI 7 of the next-hop switch, then your data segment MUST have a header with a Virtual Path Identifier of 3 and Virtual Channel Identifier of 7 when it is read by that switch. It is normal for the VPI and VCI fields in each data segment to be replaced at every hop along the way while propagating through a series of loops in a network. Services To promote extensibility, versatility, and hopefully the reliability of OCR networks VPI 0 is reserved for speaking directly to the switch. It is RECOMMENDED that each service has its own Virtual Channel Identifier at VPI 0. Furthermore, VCI 0 through VCI 4 via VPI 0 are RESERVED for future use by OCR and MUST NOT be used until an applicable standard suitably fits. It is RECCOMMENDED that features such as ROUTING PROTOCOL are provided on VPI 0, given a particular (and hopefully unchanging) VCI. Cell format Every segment of data transferred in an OCR network is called a 'cell'. Each cell is exactly the same size to reduce jitter effects, normalizing propagation latency. A cell is defined as a 51 octet data structure that contains a 3 byte header, providing 48 bytes of data transfer per cell. The format of the header is as follows: 0 15 23 <-- Bit # *----------------*--------* | VCI | VPI | *----------------*--------* Since revision 0.1.x, the order of this structure has been reversed to increase performance of the protocol by providing proper word alignment. This makes cut through switching a little more latent, but ensures that the datatypes align properly.
  15. ComputerCraft does not seem to recognise the OC Relay as any form of peripheral, and so is unable to wrap to it or interface in any way. Context: I'm using ComputerCraft Turtles to swarm mine, and send information/receive commands from a ComputerCraft computer. I placed the CC computer adjacent to the OC Relay and hoped to be able to send messages between them. I wanted to create a user interface to control the turtles on the OC screens because they have a higher resolution and I just prefer OC interface. Any help would be greatly appreciated! Currently running CC[1.80pr0], CCTweaks[1.2.4], OC[] & OC(core)[]
  16. !ereh Risgang I've written a simple program for transferring a medium sized text file (Less than about 8000 characters, roughly a small essay) over an OC network, wired or wirelessly. I've named it GFT, or "Gift", short for Gangsir File Transfer. This program is actually two small sub-programs, one for receiving and one for sending. To differentiate between them, the first argument changes the function of the program. Then, the second argument tells the file to operate on, for sending or receiving to. (To generate on receive.) Syntax is as follows: gft <send/receive> <"/path/to/file.txt"> This program copies the file being sent, so don't worry about losing the original copy. And yes, this program is small enough to send itself. (Don't know why you would, since you need this program on the receiving end anyway.) I wouldn't recommend using gft to send the file that gft is running off of, since I have not tested what happens. Uses port 20 by default, the default port for FTP in real life. Requirements for program: -Tier 1 everything -Network card -Connection between sender and receiver, if wired How to get the program: The program can be found at my github like always: https://github.com/NoahNMorton/Gangsir_MC_LuaPrograms/blob/master/OpenComputers/GangsirsSimpleFileTransfer.lua Or can be wgetted with an internet card: wget https://raw.githubusercontent.com/NoahNMorton/Gangsir_MC_LuaPrograms/master/OpenComputers/GangsirsSimpleFileTransfer.lua gft.lua Thanks for reading, and as always, let me know if you have any feedback.
  17. Hey, I'm running OpenComputers for MC 1.10.2 and I've been messing around with most things in the mod. I have a computer hooked up to a relay which is then hooked up to a server in a server rack. The problem is, I can broadcast a packet from the server to the computer but not the other way around.. when I try and broadcast a packet from the computer, the server receives nothing. Internally in the rack, both servers are able to send and receive packets from each other so I'm not sure why packets externally are not reaching the servers in the racks. http://tzli.me/XQBb3 (And yes, ports are open) Edit: On further testing it appears that network packets are blocked when there's a raid box attached to the wire.. how odd. Edit 2: I got it working, turned out there was a loop.
  18. The request-handler is a program to run as a main program on a PC. It holds execution commands from every program that communicates with it. That means I can run multiple programs that run their commands through the request-handler by adding their command and parameters to the request-handler. It also servers as a server for other computers that can send their requests to the server and if that request is allowed it will be processed automatically and the answer is send back. For this I programmed the modem-API that ensures that message networks are received on the target and works together with the request-handler. This way it is possible to run programs simultanious (like multithreaded), if they use the request-handler that runs in a main loop. It is also possible to simply run a client - server program, ask information from the server and similar. you find those libraries in my github under request-handler.lua and modem-handler.lua. It runs perfectly and was in use by me in several programs and it works awesome. I also used it in my shop-system. As I do not have time to continue the development, feel free to clone it and use the code as you wish.
  19. So, I've successfully sent a message to my friends computer. The problem is, it's just not very practical. We don't feel like going into the lua interpreter and typing things like =event.pull("modem") just to receive a message. I also don't like having to open the modem every time I get on the computer to send a message. Is there any way I could make this whole process more user friendly? Any help would be great.
  20. hi, For some reason the nano machine answer network command only in the overworld. After i pass a portal to go to any other dimension (nether, twilight, moon, mars, etc...) my nanomachine no longer answer any request. Their powers keep working and battery usage is okay. Only the network part do nothing I am alone with this problem? Is is a feature or a bug? Thank you Sylphio
  21. I have two computers. Each one has a screen and keyboard on top of each, and the two cases, but not the screens, are connected by a network cable. When the computers start up, the text appears on one screen, then the default OS screen appears on the other screen. This ends up being really confusing! I tried writing an autorun script that told each computer to set its respective screen as the primary screen component, but it didn't work. If anybody could help me out, that would be great!
  22. Izaya


    Before implimenting higher-level protocols, you'll want a lower-level way to make your messages appear as a stream, just like TCP sockets, right? That's where this comes in. ocsocket makes modems behave like TCP sockets. Functions: ocsocket.socket(port,address) That will return a socket object. Socket object functions: obj.init() Must be called to make a socket work. octcp.isData() Returns true if there is data to be read, false otherwise. obj.read(i) i is a number or character, if it's a number, it will read that many characters. If it's a string, it will read until that character appears. obj.write(string) Sends string to the target computer obj.close() Closes the socket and stops listening. And the download? http://pastebin.com/vyW5k820 Alternatively: pastebin get vyW5k820 ocsocket I reccomend you place it in /usr/lib That is all. Bai o/
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.