-
Multiplayer briefly
-
Networking!!
-
Time and Characteristics of networks
-
Packet-switching
-
Client-Server vs. Peer-to-Peer
-
Message-passing, Wire-protocols, and Discovery
-
-
Multiplayer again - Client-Server vs. Peer-to-Peer
-
Example with ZeroMQ
-
Multiplayer
-
one one or more windows
-
on one or more screens
-
on one or more computers
-
in one or more locations
-
in one or more timezones
-
on one or more platforms
-
-
turn-based simulation (sequential) vs. simultaneous simulation (time)
-
same information vs. different information vs. complete information (present information)
-
deterministic vs. stochastic simulation (future information)
-
deterministic vs. stochastic control (future information)
-
discrete vs. continuous simulation (space)
-
real-time vs. non-real-time
-
player count
-
Each player needs some view onto a globally consistent game state
-
In the general case, given laws of physics, this is impossible
-
Is possible in a number of restricted cases
-
even with incredible slow "networks"
-
-
Sometimes we just have to accept that this is not possible
-
The fundamental challenge is about getting information between parties
-
So that they can present this view onto the global game state
-
or an approximation thereof
-
-
Don’t trust external systems
-
that includes players' machines!!
-
they can be compromised, or malicious
-
⇒ server-side simulation and server-wins
-
-
turn-based simulation (sequential) vs. simultaneous simulation (time)
-
same information vs. different information vs. complete information (present information)
-
deterministic vs. stochastic simulation (future information) - ???
-
deterministic vs. stochastic control (future information) - ???
-
discrete vs. continuous simulation (space)
-
real-time vs. non-real-time
-
player count - ???
- Assumption
-
You haven’t had much exposure to computer networks.
-
We’ll try to remedy that, somewhat, today.
-
in most CS programmes networking is an entire module - you’ll be more employable if you self-study this wider
-
and if you implement networking/multiplayer things for your portfolio
-
-
-
Computers can be connected to each other to allow them to communicate with each other ! ! ! !
-
Requires hardware and software
-
both in the computer and between
-
-
Connection are made with cables, or wirelessly
-
electrical, optical, radio, ..
-
-
Other computers can sit in between and help
Many game genres are highly time-sensitive.
The laws of physics limit how fast light and electricity travel, so between two hosts there is ALWAYS a time interval for data to travel from A to B.
Networks have a number of characteristics that we are interested in, whatever the form of networking we use:
-
Latency
-
Jitter
-
Bandwidth
-
Packet-loss
-
how long it takes for data to get from A to B (one-way)
-
or to get from A to B and back to A (round-trip)
-
-
lower is better
-
bounded by laws of physics
-
speed of light, of electricity
-
-
also influenced by repeaters/hubs/switches/routers
-
also influenced by local software/hardware
-
speed of light (in a vacuum, in air, in fibreoptic)
-
\$299,792,458 \frac m s\$ - in vacuum
-
approximately \$3.00 × 10^8 \frac m s\$)
-
approximately 186,000 miles per second
-
-
-
speed of light in air is around 0.03% slower than in a vacuum (\$99.97% * c\$)
-
i.e. unimportant for us
-
-
speed of light in fibreoptic is about 35% slower than in a vacuum (\$65% * c\$))
-
this makes a difference
-
-
used for national and international links
-
doesn’t follow straight lines in the real world
-
technically the propagation speed of electromagnetic wave in cables
-
for cat5 is about 35% slower than speed of light in a vacuum (\$65% * c\$))
-
about the same as fibreoptic
-
-
these pieces of hardware are themselves computers and introduce variable delays
-
London → Amsterdam = 10ms
-
London → Paris = 8ms
-
London → Brisbane, Aus = 313ms
-
London → California, USA = 132ms
-
London → New York, USA = 73ms
-
How much data can we send per unit time (e.g. per second) - measured in Bits Per Second
-
maximum amount
-
may be limited by other factors
-
may be in conflict with other services/activities
-
-
Measured in Megabit per second (1,000,000 bits per second)
-
bits not bytes
-
rules of thumb: on the wire it takes an average of around 10 bits for each byte
-
there are various overheads
-
-
-
Ethernet
-
100 Mb/s (probably your network router, possibly your PC)
-
1000 Mb/s (1Gb/s) (probably your PC, possibly your router)
-
10 Gb/s (within the University)
-
-
Fiberoptic
-
10 or 40 Gb/s in typical system
-
400 Gb/s over single channel (single wavelength of light)
-
record for a multi-core fiber as of January 2013 was 1.05 petabits per second
-
1,050,000,000,000,000 bits per second (\$1.05 * 10^15\$)
-
-
All modern networks are packet-switched networks.
That means, that at a low level (OSI Layer 3: Network Layer) there is no concept of a connection between two nodes - only the possibility to send packets from one node to another.
Packet-switching networks exist in contrast to Circuit-switching networks.
In Circuit-switching a transmission Channel is occupied continuously while the circuit/connection is present.
In Packet-switching a Channel is only occupied when sending a packet.
Even though the underlying layer(s) may be packet-based we can simulate circuit-switched with a protocol. This gives us two conceptual modes - connectionless and connection-oriented
-
each packet includes complete addressing information
-
destination
-
source
-
port numbers
-
-
packets are routed individually
-
may result in different paths
-
may result in out-of-order delivery
-
-
packets may include a sequence number
-
Examples include: Ethernet, IP, UDP
-
requires a setup phase between hosts before useful data transfer
-
each packet just includes a connection identifier
-
rather than address information (so smaller)
-
-
end points negotiate and make sure packets are delivered in order, without errors
-
connection can be stored in the network (nodes between the hosts)
-
so routing becomes a simpler lookup
-
-
TCP is the major example here.
- IP
-
Internet Protocol (Connectionless)
- UDP
-
User Datagram Protocol (Connectionless) TCP ::Transmission Control Protocol (Connection-oriented)
-
all part of the Internet protocol suite (also known as TCP/IP)
-
There is much debate in the community around whether using UDP (connection-less, but usually with a custom protocol on top of) or TCP is better for latency-sensitive applications.
There isn’t a clear, evidence-based, consensus. I would suggest, implement at the high-level first (with a library), profile for issues.
But, the games industry tends to say most of their real-time games use UDP - http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
-
All modern games use some kinds of message-passing to communicate. Conceptually, each system only sends/receives abstract "messages" - there are (usually) no other communication paths.
-
How the message are sent between systems is up to a layer below the messaging system - i.e. most of the game engine only needs to be concerned with messages. These message MAY end up being sent on the network as one or more messages.
-
depending on the technique, messages may have issues:
-
may not arrive
-
may arrive out of order
-
may arrive twice
-
may be corrupted (rare)
-
-
-
Being able to send messages around is all well and good, but what should we put in the messages?
-
How do we know/define the wire-protocol?
-
How do we make it efficient?
-
Endianness?
-
…
-
-
Many many options here, including making your own
-
We’ll look at some in our serialization lecture
-
Most, modern games use Client-Server
-
easier to implement
-
makes firewall/NAT issues easier/possible
-
makes security/trust easier/possible
-
For this module, you live in an easier world
-
LAN only
-
assume no message loss (realistic assumption on local network)
-
assume messages in order (realistic assumption on local network)
-
assume known IP address (command line or config flag?) (manageable with a manual method)
-
-
Same machine architectures
-
same endianness (All Labs are x86/x64)
-
-
Same versions
-
both (all) machines have the same software version (manageable with a manual method)
-
-