eScience Lectures Notes : .
Slide 1 : 1 / 26 : Communication Architectures
Communication Architectures
Slide 2 : 2 / 26 : Communication Architectures
Communication Architectures
Based on Chapter 4 of "Networked Virtual Environments..." (Singhal
and Zyda)
Logical architecture vs Physical architecture
Client/Server vs Peer to Peer
Slide 3 : 3 / 26 : Two Players on a LAN (Local Area Network)
Two Players on a LAN (Local Area Network)
-
Logical architecture --> Message flow
-
Physical architecture --> How is it really wired & how do our messages
really flow?
-
What are the limitations ?
Slide 4 : 4 / 26 : Latency
Latency
100 milliseconds ... typical VR feedback loop
200 milliseconds
Or what?
How long before we cant control or react to the other players across
the net? This the THE BIG DEAL, IN FACT THE WHOLE DEAL with Net-VEs.
For Online Game addicts, only one question : "What is your ping ?"
-
speed of light delays (~ 10 ms of delay per time zone)
-
light trough fibber : 200kkm/s, 44835km/24 = 1868km => 9,34ms
-
delays from the computers themselves
-
software (OS) and network Hardware
-
delays from the network : the routers (gateway) work
-
ethernet to the LAN : 10 ms
-
modem on phone system : 100 ms
-
transcontinental transfers + 60-150 ms
-
intercontinentals latencies + 250-500 ms
Slide 5 : 5 / 26 : Case study : DIS Protocol and PDU
Case study : DIS Protocol and PDU
The DIS (Distributed Interactive Simulation ) network software architecture
is a direct descendent from SIMNET but has packets that are more general than
SIMNETs.
DIS has the same three basic components
-
an object-event architecture
-
notion of fully distributed simulation nodes
-
embedded set of predictive modelling algorithms for dead reckoning
Each Event is a packet sent over the network called a Protocol Data Unit :
PDU
The form of a PDU is standardised :
144 bytes in length and contains the information necessary to manage entity
state for the various players.
Identification of the player, player's location, orientation, velocity acceleration,
any articulation information for the player, any dynamic information about the
player that need to be communicate.
Other hypothesis : Graphics performance - 30 frames per second.
Thanks to predictive modelling algorithms, there is no need to systematically
send a PDU every frames
Slide 6 : 6 / 26 : NPSNET-IV Performance with DIS
NPSNET-IV Performance with DIS
From experience and type of behaviour of these objects
-
Aircraft 12 PDUs per second
-
Ground vehicles 5 PDUs per second
-
Weapon firing 3 PDUs per second
-
Fully articulated humans 30 PDUs per second (frame rate)
-
Heartbeat PDU every 5 seconds.
Slide 7 : 7 / 26 : Some network parameters
Some network parameters
-
56 kbps for V.90 modems
-
256 kbps - 1 Mbps for Cable Modem and ADSL
-
1.5 Mbps for T-1 lines
-
10 Mbps for our Ethernet LAN (saturates at 70% utilisation)
-
100 Mbps full duplex
Question : How many players / objects can we support with these different
bandwidths ?
NB. We forget any other use of the network : no mail, no web browsing, no
NFS, no overhead, and assume that only the network is the bottleneck
Slide 8 : 8 / 26 : Ethernet Bandwidth
Ethernet Bandwidth
From official 10 Mbps to 7 Mbps of available bandwidth (above, saturation)
Aside questions to Markus Buchhorn :
Where those that limitation commes from ?
The 70% number came from shared Ethernet, where everybody
effectively shared a single cable, and only one machine could talk at a time
- statistically you could not run data on it more than 70% of the time, and
it is 10Mb/s total across all the connected devices.
Switched Ethernet is different, in that it's only you and the switch on that
single cable.
What about 100 Mbps and 1Gbps ethernet ?
Both of these are only run in switched mode, not in shared mode.
Over that, you need to take care of the usual protocol overhead costs
Is there some way (tables...) to easily evaluate these
costs or is it necessary to sniff your network each time you want to be sur
that you have enough bandwidth available (Of course, you have to do that on
a shared network, but on your local ethernet, you should be able to be more
in charge ?
You can look at tables or standards documents to identify
protocol overheads. In general these are "pretty small", around 10%
or so.
In terms of measuring if you have enough bandwidth available - you can't do
that deterministically on any frame/packet based network. You cannot predict
when another device will send a burst of large packets, which fill up buffers,
or a very large number of small packets, which chew up the CPU. This can vary
on timescales from milliseconds to mega-minutes. All you can do is look at the
path and identify where you might see congestion. Applications running over
IP have to be able to deal with congestion, leading to latency and jitter, or
leading to packet loss, or routing changes that also impact latency and jitter.
A sad fact, but that's also the power of the Internet.
On your local network, the main bandwidth constraint is the switch in the middle,
and then any other applications that are talking to your two endpoints. If you
have two PCs on their own on a dedicated switch and no other applications, you
should be able to get close to 100% throughput. I've seen over 95Mb/s transport
rate on a 100Mb/s Ethernet network.
If you have a need to guarantee bandwidth, there are some ways you can do that
- Ethernet and IP both allow traffic to be tagged with 'priorities', giving
those frames/packets better (or worse) treatment than other traffic. That requires
support from the hardware along the way though, and is not a 100% guarantee
in all cases. To get guarantees like that requires a more deterministic network
like ATM and its virtual circuits.
A PDU is 8 bits/byte times 144 bytes or 1152 bits.
NB. : Mbps = 1000 x 1000 bps, kbps = 1000 bps, Gbps = 1000 Mbps
Meaning we can send about 6,076 PDUs per second on our Ethernet LAN.
If we assume mayhem, all players firing once each second, we can make some
statements about the outer bounds of what we can support.
-
Fully articulated humans (30 PDUs/second) firing once per second (3 PDUs/second)
--> we can have 184 humans on such a LAN.
-
Assume all aircraft (12 PDUs/second) firing once per second (3 PDUs),
we can have 405 aircraft.
-
Assume all ground vehicles (5 PDUs/second) firing once per second (3 PDUs),
we can have 759 ground vehicles.
So we can support between 184 to 759 players on our LAN, assuming away all
other usage.
NPSNET-IV maxed out at about 300 players.
Slide 9 : 9 / 26 : V90. Modem
V90. Modem
56Kbps implies about 48 PDUs/second.
1 human, 3 aircrafts or 6 ground vehicles.
If we do better than that and make our packets only 22% of that size (32 B
instead of 144), we can have 218 PDUs/second.
6 humans, 14 aircrafts or 27 ground vehicles.
Slide 10 : 10 / 26 : How many players can we support with a DIS-like architecture?
Players supportable in a DIS-like networked virtual environment
versus various available network technologies.
Assumptions
|
|
1. Infinite compute cycles at each node.
|
|
|
|
|
2. Infinite graphics cycles at each node.
|
|
|
|
|
3. Network interface with infinite cycles.
|
|
|
|
|
|
|
|
Bytes
|
Bits
|
|
|
Packet size for DIS-like VEs =
|
|
144
|
1152
|
|
|
Packet size for Game-like VEs =
|
32
|
256
|
|
|
|
|
|
Just moving
|
Mayhem
|
|
|
Articulated humans (PDUs/second) =
|
30
|
33
|
Mayhem used for Min. Players
|
Aircraft (PDUs/second) =
|
|
12
|
15
|
Not used but here for completeness.
|
Ground vehicles (PDUs/second) =
|
5
|
8
|
Mayhem used for Max. Players
|
Technology
|
Min. Speed
|
Max. Speed
|
Min. Players
|
Max. Players
|
Min. Players
|
Max. Players
|
|
bps
|
bps
|
DIS-like
|
DIS-like
|
Game-like
|
Game-like
|
V.90 Modem
|
28,800
|
56,000
|
1
|
6
|
7
|
27
|
|
|
|
|
|
|
|
DSL
|
384,000
|
1,500,000
|
39
|
163
|
178
|
732
|
|
|
|
|
|
|
|
T-1
|
1,500,000
|
1,500,000
|
39
|
163
|
178
|
732
|
|
|
|
|
|
|
|
Cable Modems
|
2,000,000
|
10,000,000
|
263
|
1085
|
1184
|
4883
|
|
|
|
|
|
|
|
10BT
|
7,000,000
|
10,000,000
|
263
|
1085
|
1184
|
4883
|
|
|
|
|
|
|
|
100BT
|
70,000,000
|
100,000,000
|
2630
|
10851
|
11837
|
48828
|
Slide 11 : 11 / 26 : Multi-Player Client Server - Logical Architecture
Multi-Player Client Server - Logical Architecture
Servers are bottlenecks!
But useful for compression & admin tasks
-
reduce message traffic to individual players by not sending packets
-
compress multi packets into a single message
-
convert bursty packet reception into smoother paket rates
-
administrative task such as accounting
Slide 12 : 12 / 26 : Multi-Player Client Server - Physical Arch. on a LAN
Multi-Player Client Server - Physical Architecture. On a LAN
Messages to and from the server from all players travel on the
same wire !
For a server to be meaningful in that physical architecture,
the server must be performing some added value function
-
collecting data and redistributing them in a compressed form.
-
doing some computation that the player machines are not capable
of.
It might really look like this physically!
Slide 13 : 13 / 26 : Multi-Player Client Server - Physical Architecture - Phone Lines
Multi-Player Client Server - Physical Architecture - Phone Lines
This physical architecture matches the logical one
-
Usually the one use for Internet games
-
Kali, Ten, MPlayer
-
between 32 to 128 players
-
Higher latency... to let the server compress and merge packets
-
Game servers need to provide accounting
Slide 14 : 14 / 26 : Multi-Player Client Server with Multiple Servers
Multi-Player Client Server with Multiple Servers
Or this, if we are using a multi-player video game service company
...
Need High bandwidth between each server (100 Mbps LAN ... )
Well adjusted to Spatial partitioning of the Virtual Environment
Slide 15 : 15 / 26 : Peer-to-Peer
Peer-to-Peer
No Server, because Servers mean that eventually, we cannot scale our Net-VE
Communications go directly from the sending player to the receiving players
When each player speaks directly to the player/players to whom it needs to
communicate state.
Could be done using TCP/IP (and a server that keeps a
list of the set of players), UDP, Broadcasting or Multicasting !
Slide 16 : 16 / 26 : Peer-to-Peer on a Lan
Peer to Peer ... ... on a Lan
Again, unicasting (TCP or UDP) is possible
but not at all adapted (not scalable).
Broadcast
-
Each packet is received (and read) by all players (and computers) on the
LAN : busy LAN and busy computer !
-
Floods the network with packets.
-
All packets must be brought up through the kernel of the operating systems
of all players on the net.
-
Even if the packet is not for that machine!
-
Thereby wasting CPU time.
NB. in WarCraft, we need a server even on a LAN because of Licensing issue
(the CD is the key !)
Slide 17 : 17 / 26 : Peer to Peer Multicast
Peer to Peer ... ... on a Lan or anywhere
Multicast
-
Multicast services allow arbitrarily sized groups to communicate on a
network via a single transmission by the source.Don't disturb (or less)
non player computers (even if the network is still as busy !)
-
Possibility of AOIM : Aera Of Interest Management
-
Eg. : Geometric partition of the Net-VE, with each region being assigned
a multicast address
Slide 18 : 18 / 26 : VE Software Scalability Statement
VE Software Scalability Statement
Virtual environment software architectures can exploit wide area multicast
communications and entity relationships to partition the virtual world and enable
the development of scalable VEs.
Areas of interest in the VE
-
In the real world, which virtual environments emulate, entities have a
limited “areas of interest”.
-
We can exploit this with multicast communications.
-
Interactions are mediated by an AOIM (Aera Of Interest Management) software
layer.
Slide 19 : 19 / 26 : AOIM (Aera Of Interest Management)
AOIM (Aera Of Interest Management)
Partition the simulation into workable chunks to reduce computational load
on hosts and minimize communications on tail links.
Distribute partitioning algorithms among hosts.
Different possible partitioning classes
-
Spatial
-
Functional / by Entity
Slide 20 : 20 / 26 : Spatial Partitioning of the VE Using AOIM
Spatial Partitioning of the VE Using AOIM
Slide 21 : 21 / 26 : AIOM Software Layer
AIOM Software Layer :
-
a Multicast IP adress for each AOIM
-
a UDP port for each AOIM
AOIM (Aera Of Interest Management)
Slide 22 : 22 / 26 : How to set up a Client Server Architecture
How to set up a Client Server Architecture
-
Launch the Server with a chosen port number
-
Send (Real world or mail, or web or DNS) the IP number / port to all potential
users
-
Let each user connect to the server
-
Let the NVE begin (using TCP or UDP)
Slide 23 : 23 / 26 : How to set up a Peer to Peer Architecture
How to set up a Peer to Peer Architecture
-
Chose broadcasting or multicasting...
-
Chose either some ports number, and IP scope (broadcasting), or some Multicasting
IP Number
-
or even TCP and UDP, with a registration server
-
Let each client take care to send its position/speed... to the subpart
of the full network or to the Multicast address
Slide 24 : 24 / 26 : Blizzard : World of WarCraft (WoW) : FAQ
Blizzard : World of WarCraft (WoW) : FAQ
What is World of Warcraft?
World of Warcraft is a Massively Multiplayer Online Role Playing Game (MMORPG).
In World of Warcraft, thousands of players will have the
opportunity to adventure together in an enormous, persistent game world, forming
friendships, slaying monsters, and engaging in epic quests that can span days
or weeks.
We have not yet announced a release date
for World of Warcraft. MMORPGs are vast and complex; we want to make sure that
we take the time necessary to develop a game that will meet the high standards
that our developers and fans have come to expect from Blizzard games.
What are the game's system requirements?
We have not yet finalized the system requirements for World of Warcraft. As
with our past games, our goal is to ensure that the game will
run on a wide variety of 3D cards and at a wide range of processor speeds.
For what platforms will the game
be available?
The game will initially be available for PCs.
How will World of Warcraft differ
from other MMORPGs?
World of Warcraft will differ from other MMORPGs in many ways. One of our main
goals is to ensure that players can enjoy World of Warcraft
without having to invest huge amounts of playtime. Players will be able
to complete quests and experience the world at their own pace-whether it be
a few hours here and there, or week-long adventuring marathons. Additionally,
our quest system will provide an enormous variety of captivating quests with
story elements, dynamic events, and flexible reward systems. World of Warcraft
will also feature a faster style of play, with less downtime and an emphasis
on combat and tactics against multiple opponents. We also plan to incorporate
several unique features, which we'll disclose throughout the course of development.
Is Blizzard aware of some of the
game play problems that have been prevalent in other MMORPGs?
Yes. Blizzard employees are gamers first and foremost, and we have played more
than our fair share of existing Massively Multiplayer games. We tend to agree
with MMORPG gamers on the strengths and weaknesses of the genre to date. We
will strive to advance the genre by both building on its positives and improving
its negatives.
Will World of Warcraft mix with
Warcraft III? If there are new foes, do they include the Night Elves, Undead
or Burning Legion?
World of Warcraft will be set in lands both familiar and new to long-time players
of the series. It is difficult to discuss the World of Warcraft story without
giving away the plot for Warcraft III. We can say that Azeroth will experience
significant changes and be a very different world than Warcraft fans know today.
And, while there will be plenty of recognizable characters and places to explore,
we think that the balance between discovering what is known and what is different
is something that players will really enjoy.
In regard to the inclusion of the Night Elves, Undead
or Burning Legion, you will just have to wait and see...
Does the game require
a 3D accelerator?
Yes, the game will require a 3D graphics card. Again, we will support a wide
range of 3D cards.
Will the game be
playable over a modem?
Yes.
Will there be monthly
fee to play the game?
Yes; however, we are still investigating our business model and have not yet
determined what the fee will be.
Why isn't World of Warcraft free?
World of Warcraft will require a fee to play. This fee will be used to support
the costs associated with the high-quality levels of service, support, and ongoing
content creation that we are planning for World of Warcraft.
How will the game be distributed
or sold?
Gamers will be able to purchase World of Warcraft at retail outlets, online
sites, or directly from Blizzard Entertainment. However, in
order to play you will need to sign up for a monthly account.
Will there be Cinematic sequences
in the game?
Yes. The Blizzard Film Department will create cinematic sequences for World
of Warcraft. We do not anticipate, however, that the game will have as many
as our previous games due to the nature of Massively Multiplayer Role Playing
Games. You can see the first cinematic for World of Warcraft on the
movies page.
Will players have the opportunity
to provide feedback about the development of the game?
Yes. Players will always be able to share their input via the Battle.net
forums and beta testing. We also plan to devise additional methods for players
to communicate with the developers.
Does Blizzard plan
on addressing Kill Stealing and Item Farming?
Yes, and we will reveal more details on our plans at a later date.
Will you be able to randomly find
items, and if so, will these items be classified as in Diablo II (Rare, Unique,
etc.)?
Monsters will have treasure that characters can loot, but these will be drawn
randomly from a specific item class for that monster type. We
do not expect to have the same vast amount of random items as in the Diablo
series, but we will have items that are rare and even some that could be truly
unique by limiting them to only one per server.
Slide 25 : 25 / 26 : Blizzard : Battle.net
Blizzard : Battle.net
What changes have been made to Battle.net since the release of Diablo II?
Blizzard Entertainment continues to make several enhancements to the Battle.net
infrastructure by increasing the number of servers and
providing additional bandwidth.
Beginning June 2000 and continuing through August 2001,
we have increased the number of game servers in our Asia gateway to 300, increased
the number of servers in the US gateways to 200 and raised the number of servers
to 100 in the Europe gateway.
We have also added two new Asian Realms to our Diablo II world as well as increased
the size of all Realms. The Battle.net team is extremely committed to providing
our users with the best possible game play experience. In order to provide this
experience, we have also expanded the number of personnel dedicated to Battle.net.
These changes were put into place in order to make your gaming experience enjoyable
while maintaining our dedication to keeping Battle.net a complimentary service.
Why are players from another country on my Diablo II Realm/Battle.net Server?
Anyone in any country is free to play on whatever Realm
or Battle.net Gateway they choose. This is not changing. The Diablo II
Realms and Battle.net Gateways are named to give people an idea which one is
best to pick based on their location. They are NOT named to suggest ownership
of the realms by geographical areas or to suggest who has to play where. Please
respect people's right to play on any server they choose.
Why do you allow people from all over the world to connect to any Diablo II
Realm or Battle.net Server?
We want to allow friends from around the world to be able to play together
on the same server. To do this, the servers must be open to anyone. We have
no intention of restricting access based on location.
Gateways
Gateways acts as portals through which players get onto
Battle.net. The four Gateways that Blizzard maintains are: US West, US East,
Asia or Europe. For the best play experience, you should select the Gateways
that is closest to your geographic location.
You cannot talk to or play games with players on other Gateways. To play together
you must select the same Gateway.
The 19/08/02 :
USERS ONLINE:
247,156
CURRENT GAMES:
99,043
Slide 26 : 26 / 26 : Simnet Case Study
Simnet Case Study : Michael Zyda team
Does partitioning using the chosen architecture reduce bandwidth and computational
requirements for large-scale virtual environments?
Does the architecture scale and if so how well?
-
Get real world data from the National Training Center from a battle scenario.
-
Use constructive model on the real world data to fill in the player positions
and actions.
-
Run a simulation of the Area of Interest Manager and kept records on the
distribution of players among the hexes.
-
Peak Multicast traffic around 2Mbits/second, just over T-1 speed.
-
Peak at 1,500 players in an area of interest for Multicast.