Search the Community
Showing results for tags 'ocranet'.
Found 4 results
OHML being complete, it just needed something next so the OHML specification is complete. And this thing is what is here: OHTP Definitions: Host - Any computer or machine with a OC-compatible modem attached to it Server - Host sending OHTP-valid data when an user attemps to connect Client - Host receiving OHTP-valid data from a Server OHTP - Open Hyper Text Protocol - Protocol used to transmit OHML - Open Hypertext Markup Language between Hosts. Specifications: The OHTP protocol doesn't take care of what is transporting it. Either it is using a socket API, going through modem, minitel or GERT. It assumes the API or transport layer you utilize supports sockets. Arguments in URLs: To put arguments inside URL, the url must end like normal, but have "?" at end, followed by "property=value" entry. If wanting to add more entries, add "&" after last entry Example: ohtp://1001.1002:1003.1004/index.ohml?username=admin&password=admin writeTable/readTable, Fuchas's liblon, etc. User Agents: User agents are standard strings defining what browser and what layout engine a user is using. It can be used for metrics and/or compatibility purposes (in case standards aren't fully respected). An user agent is presented in the following form: BrowserName/BrowserVersion, LayoutEngine/LayoutEngineVersion where LayoutEngine is the layout engine and LayoutEngineVersion is layout engine's version, etc. The format has been thinked to be simple making it easy to parse. Since it's just 2 fields separated with a "," (Browser name and version + Layout engine name and version), and in those fields, the name and version separated with a slash (/). Parsing user agent is in this case, just some splitting of strings. For example with Icecap browser (coming soon): Icecap/0.1, Geeko/1.0 Peanuts: Peanuts are data stored as text files in a key=value scheme. They are handled on client-side and are only edited by server. He edits it by sending a response property (Set-Peanut) to client. A Peanut Group (peanuts) is separated by ";". Making ";" the only invalid character in peanut key and value. Server is aware of Client peanuts by the Peanut request property. Which sends peanuts as a Peanut Group. Of course this property is optional as a client doesn't always have peanuts. Now the most important note about peanuts: When a server send a Set-Peanut property. The peanut must be set for the whole website and not only the current page! Connection: OHTP PORT SHOULD BE 80 Client-Side: Once the socket is opened, the Client can ask data to Server The Client will send first a Request Header looking like it: OHTP/MAJOR.MINOR REQUEST PAGE Example, if the REQUEST is GET, and the version 1.0, with a request page equals to /index.html (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /): OHTP/1.0 GET /index.html Currently the valid REQUEST values are: GET (just receive the file) There are also request bodies, which just include "Property: Value" entries. Non-standard properties, must start with "X-" Standard Properties: Standard properties are for now: Peanut - Inform server of currently saved peanuts (see Peanuts) User-Agent - User Agent of the current browser (see User Agents) Referer - If redirected from a link, equals to the previous website URL. So a request is constructed like that: Request Header( + Request Body) The client, even after having received the Response from Server can still send new requests. All that until socket is closed. Example Request (whole): OHTP/1.0 GET /index.ohml User-Agent: MineScape/1.0, Geeko/0.9 Peanut: login=true;username=admin;password=admin X-Non-Standard-Header: non standard value Server-Side: Once the Server receives a Request from a client. It must replies with a Response. A Response is contructed like this: Response Header + Response Content The Response Header is constructed like this: ERRORCODE Response Body Response Content Yep, i know it's really small, making it simple to implement. Currently there are thoses error codes: 200: OK 201: Moved permanently + new URL after ERRORCODE 300: Temporaly moved + new URL after ERRORCODE 301: Switch protocol (e.g.: 301 OHTP2) + approved protocol name after ERRORCODE 302: Switch network protocol (e.g.: 302 minitel) + approved protocol name after ERRORCODE 403: Invalid request 404: Page not found 500: Server error 501: Internal error sending the the fetched page (e.g. file found but not accessible from server). 502: Server-side language is errored (Detailled version of 500, optional) 503: Service temporaly down The Response Body is just a bunch of standard properties exactly like in the client-side request body. However the valid properties changes for Server. Standard Properties: Set-Peanut: Sets a peanut on client. Content-Size: The size of the content. Useful for long downloads! Content-Type: As specifying OC content types would require a whole new topic. Can just be equals to "page", "resource" or "download". Page is OHML, Resource are resources like images, and download is everything meant for download (Lua files, installers, compressed files, etc.). Update: While "page", "resource" and "download" are still accepted, please use MMTI Like Request properties, unstandard ones start with "X-" The Response Content is just the content of the fetched file (if found). THE RESPONSE CONTENT MUST BE SEPARATED FROM RESPONSE BODY WITH A LINE BREAK (\n) Example Response (whole): 200 Set-Peanut: isadmin=true Content-Type: text/ohml <ohml> <text>Hello World!</text> </ohml>
Globally Engineered Routing Technology (GERT) is a networking protocol for OpenComputers that can network OC computers together, and connect different MC servers together via the Internet. It is also capable of linking real life computers to OC Computers. This post is dramatically being revised, but more information can be found at https://github.com/GlobalEmpire/GERT/wiki/GERTi For more questions, please either post in this thread, or message MajGenRelativity#4971, Gavle#9328, or TYKUHN2#5283 on Discord. Messaging MajGenRelativity on irc.esper.net is also an option if you can't/won't use Discord.
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.
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.