Intergalactic Stargate Portal Network

Intergalatic Stargate Portal Network

There is a massive network of connected techno-portals which can warp objects and people between them using an unknown protocol. It is not exactly known who created these portals or the protocols they use but thanks to extensive efforts by the Guild of Technomancers Intergalatic, the Stargate Portal Technology and Protocols have been fully reverse-engineered.

As such, a modified version of the Stargate Portals has been created. With an intergalactic standard protocol suite based off of the Earthling Internet Protocols. It has been named the Stargate Protocol or SP for short. From there, the Intergalactic Stargate Portal Network (ISPN) has been built as a universal standardized teleportation technology.

The current version is SPv4. Although a security enhanced SPv6 is in the works.

The SP Protocol Suite currently includes:

1. A Dial-Up handshake protocol called the Binary Subscripture Handshake Protocol (BSHP)

2. A TCP/IP Style Protocol called the Stargate Transport Protocol (SGTP)

Each Portal has a "Dialing Address" known also as a "Stargate Protocol (SP) Address" which is tied to a single portal.

Each SP Address is 9 symbols long. There are 39 possible symbols to use so each segment is 6 bits in size with the maximum being 100111 which is 39 in binary. In binary this means the number of SP Addresses goes from 000000.000000.000000.000000.000000.000000.000000.000000.000000 to 100111.100111.100111.100111.100111.100111.100111.100111.100111 or in decimal 0.0.0.0.0.0.0.0.0 to 39.39.39.39.39.39.39.39.39 accordingly.

This means that there can be at most 208,728,361,158,759 possible SP Addresses. Since the SP standard works almost exactly like the IP standard, these addresses can be:

1. Assigned statically and dynamically.

2. Divided into classes. We currently have Class A, B, C, D, E, F, G, H, and I Addresses.

3. Have reserved spaces for specific purposes. For example the 27.0.0.0.0.0.0.0.0 address space is reserved for Loopback purposes only.

4. Be subnetted.

These custom portals use a universal set of symbols to ensure compatibility and the SP standard mandates that all portals that connect to the ISPN support this symbol set. Note that this is different then the original Ancient designed Stargates. However legecy support for the original portals are also implemented in SP standard using different protocols for interoperability purposes.

When a SP address is entered/selected on a portal, it broadcasts a request across the network to locate it. If it can be found then a Binary Subscripture Handshake is initiated between the two. If it cannot be found, reached, the connection is refused, is invalid, or the request packet times out, then an error is thrown.

Binary Subscripture Handshake Protocol (BSHP) process:

1. Dialing portal sends a Binary Subscripture (BINSUB) REQ Packet to the Destination Portal. It lists the available spectral transmission frequencies that that Dialing Portal supports.

2. Destination Portal receives the BINSUB Packet and sends a BINSUB ACK Packet listing its supported frequencies.

3. A negotiation takes place between both portals to agree on which frequency will be used for this session. REQ and ACK packets are exchanged.

4. A connection test is performed and if successful, both portals will open to allow transport.

A Standard Stargate Transport Protocol (SGTP) Packet consists of:

1. Addressing Field

1a. Originating SP Address

1b. Destination SP Address

2. Cartograph Field

2a. Originating Cartograph Data

2b. Destination Cartograph Data

3. Binary Subscripture Field

3a. Inbound Binary Subscripture Data

3b. Outbound Binary Subscripture Data

4. Attamatter Field

4a. Attamatter Block Sequence Number

4b. Attamatter Data Block

4c. Attamatter Hash Checksum

Addressing Field: Contains the SP Addresses of both portals.

Cartograph Field: Contains the spacial coordinates for the host portals. This is only used when connecting to portals that use the original Ancient designed legacy protocols. Otherwise it is left blank.

Binary Subscripture Field: Contains the precise frequencies of both hosts spectral transponders, allowing anything within the teleportation matrix/event horizon to warp from one point to another.

Attamatter Field: Contains schematics for atomic mapping, allowing a host portal to disassemble/reassemble the molecular structure of anything that passes though the teleportation matrix/event horizon.

After the Binary Subscripture Handshake is complete, the resulting data is then stored in the portal's temporary memory and added to all SGTP Packets Binary Subscripture Field during the session.

Objects that enter the portal are mapped by the Attamatter Modem and an atomic mapping is performed to create a schematic of the object. This schematic is then broken into small blocks and each block is encoded into an SGTP Packet which is then sent over the network to the destination portal.

To prevent errors and ensure safe passage, the object is not transported though to the other end until the destination portal receives all of the packets. This is done using the same error prevention that Transport Control Protocol (TCP) uses along with its own method:

First, the schematic is given a checksum with a cryptographic hash function before being split into packets and this checksum is attached to Attamatter Field of each packet that carries a piece of the same schematic. This allows multiple objects to pass through at once and be sent to different destinations.

Second, each SGTP Packet is assigned a sequence number to ensure that the schematic is received in the order it is sent. An ACK Packet must be sent back by the destination portal and read by the sending portal before the next numbered Packet is sent. This is identical to the TCP protocol.

Third, once a full schematic it received by the destination portal, its hash checksum is calculated and compared with the attached hash checksum to verify that it has not been corrupted in transit. If the hashes match, then the object is transported through the portal. If they don't match, then the destination portal sends the originating portal a packet that is the equivalent of "Didn't get that, send it again." and the entire process repeats for that particular object.