OtterLib Team C. Vidal
Internet-Draft Epitech
Intended status: Informational 8 March 2023
Expires: 9 September 2023
OtterNetwork's UDP Communication Protocol (OUDPCP)
otternetwork-internet-draft
Abstract
This document describes the network protocol of the OtterNetwork
module for the OtterLib game engine.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 September 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Vidal Expires 9 September 2023 [Page 1]
Internet-Draft OtterNetwork March 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Specification . . . . . . . . . . . . . . . . . . 3
2.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Establishing a connection . . . . . . . . . . . . . . . . 4
2.3. Reconnecting a lost connection . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Informative References . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
The objective of the OtterNetwork UDP Communication Protocol
(ONUDPCP) is to be an easy to use, implement and exetend network
protocol for game engines. The protocol is UDP based and meant to
send primarily unimportant messages. Important data can be sent
reliably at the cost of efficiency.
This paper assumes basic knowledge of the User Datagram Protocol
(UDP) [RFC0768].
1.1. Interfaces
The ONUDPCP interfaces on one side to the OtterCore engine and on the
other side to the lower level protocol UDP.
The interfaces between the OtterCore and ONUDPCP and between UDP and
ONUDPCP are both explained within this document. They consist of a
set of calls like an operating system provides for manipulating
files. There are calls to send data and close connections.
1.2. Terminology
endpoint
An endpoint is a combination of an Internet Protocol (IP) Address and
a port allowing to uniquely identify a host on the network.
ONUDPCP message
An ONUDPCP message is a single data serialized with boost binary
archive. It can be anything as long as it's not larger than the size
of an UDP datagram minus the size of the size of the ONUDPCP header.
ONUDPCP packet
Vidal Expires 9 September 2023 [Page 2]
Internet-Draft OtterNetwork March 2023
An ONUDPCP packet is an agregate of ONUDPCP messages preceded by the
ONUDPCP header.
2. Functional Specification
2.1. Header Format
ONUDPCP packets are sent in UDP datagrams. The UDP header already
carries several information fields, including the source and
destination host endpoints.
ONUDPCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Count | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 1: ONUDPCP Header Format
Magic Number: 32 bits
The magic number identifying the game protocol used.
Sequence Number: 32 bits
The sequence number of the packet, used to keep track of lost packets
and acknowledges.
Client ID: 32 bits
Used to identify the client uniquely, allows for seamless
reconnection with a different endpoint.
Message Count:
Number of ONUDPCP messages in the packet.
Vidal Expires 9 September 2023 [Page 3]
Internet-Draft OtterNetwork March 2023
2.2. Establishing a connection
The connection is implicitly started on client first packet, when the
server gets an ONUDPCP packet it first checks the magic number to
ensure the right version is being used, then it checks a list of
currently active connection based on the Client ID, if the Client ID
is 0 or not in the list the server adds the client in the list by
storing it's endpoint and gives it an ID which will be sent to the
client in the next response.
2.3. Reconnecting a lost connection
When a server receive a packet with a known ID but from a different
endpoint, it must consider it as a reconnection. The stored endpoint
must be updated to match the new connection.
3. Security Considerations
As this protocol isn't meant to be used for critical operations, no
security considerations were added to it's conception. A connection
could easily be overtaken using the reconnection mechanic.
4. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
Author's Address
C. (hollow) Vidal
Epitech
Email: corentin.vidal@epitech.eu
Vidal Expires 9 September 2023 [Page 4]