There are two main transport protocols that the computers use to deliver data from applications to the network and vice versa. They are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

There are some main differences between TCP and UDP:

TCP provides reliable communication with error detection and recovery. The data delivered by TCP is in segments that are in order. TCP is used in most applications that require accurate data delivery such as WWW, e-mail, and file transfer. Except the latest Flash Real-Time Media Flow Protocol, all Flash connections used the TCP protocol.

UDP, on the other hand, does not have error recovery and does not guarantee the data is delivered and the order may not be in sequence. However, UDP is so simple that the header size is much smaller than TCP. The small header size and missing error recovery lets UDP give shorter latency and higher throughput. Thus UDP is often used in multimedia broadcasting applications that require faster delivery and allow transfer error.

Peer-to-peer network means every machine connects to the other machine in the same network. In this network, every peer node listens to the requests and provides results to each other.

Recently in the Flash player 10.1, Adobe introduced the Real-Time Media Flow Protocol (RTMFP) that supports peer-to-peer connections between Flash clients on top of the UDP protocol. The Flash clients can rely on the Adobe status server, which is in Beta now, to locate and authoricate the peers or directly locate peers in the same local network.

One advantage of peer-to-peer network is that there is not a master computer. Every machine in the network does the same task and thus there is no single point of failure in the network. The network application keeps working when any machine downs.

Another advantage of the peer-to-peer network is that the latency between two computers is half compared to the client-server model of communication. The computers are communicating to each other directly instead of delivering the message by another computer in middle.

Peer-to-peer network is useful for multiplayer applications or games that divide the users into small groups. They can benefit from the peer-to-peer approach that computers in group are communicating directly to their targets and the network bandwidth used in each group will not affect the others.

However, there are some disadvantages that make it not suitable to use in a virtual world with massive multiplayer.

As there is not an administrative machine, every machine is the same and they all need to have a copy of all logic and data in local. Users will have access to all critical data and can easily modify the data without validation. Hacked clients can send out altered messages to other peers to cheat them. This raises the security problem that the hacked clients can claim to have unlimited health points or claim that all attacks are missed.

Moreover, every machine establishes connection with each other. This make the number of connections grow quadratically with the increasing number of nodes. There are a total of 5050 connections when there are 100 machines in the network. What if there are 1000 machines and 50,000 connections? Imagine that there are 100 players now in the virtual world and all 100 players are doing different tasks and then broadcasting to each other in every second. The whole network will be overloaded.

Another disadvantage is that the connectionless characteristics of UDP may make peer-to-peer connections fail on computers that are behind a firewall or NAT. The following diagram shows the peer-to-peer architecture:

Client-server network means there is a centralized server and every machine connects to this server. The server computes requests from client machines and provides results to client machines that need the results. What clients do is just send a request to the server and display the results. There can be few or even no logic in client side.

This network is usually used in virtual world because there are only N connections between N clients and the security is enhanced as most critical logic and data is in the server so that users cannot modify it themselves.

Take the previous 100 machines in Peer-to-peer section as an example. There are 100 players in the virtual world with the server-client machine now. When one player sends a broadcast message to tell others, the message was sent to the server and the server distributes the messages to all other 99 machines. The following diagram shows client-server architecture:

Clients need to keep communicating with the server to keep the whole virtual world synchronized among clients. There are two methods to keep the communication with the server — polling and socket-based.

Polling

Polling refers to the activity wherein the clients keep asking the server for updated status in an interval. It is usually used in multiplayer applications that do not have persistence connections. It could be a PHP chat application or chess game played by two players.

The implementation of this method is easy and thus may be used by developers who are new to multiplayer applications. However, we should not use this approach in Flash. Instead we should use the socket connection from Flash to establish persistent connections to the server.

In the polling approach, clients need to keep asking the server for an update even when there are no updates most of the time. This wastes a lot of bandwidth and greatly increases the server loading. It is a bad practice to use polling in massive multiplayer applications and we should avoid it throughout the development of the virtual world.

Take an example of how a turn-based Tic-Tac-Toe with polling performs poorly.

When two players connect to the server and are ready to start playing tic-tac-toe together, player A is thinking where to put an "X" on the board. When player B is waiting, his machine asks the server if there are any updates from other players per second. After a while, player A put an "X" in the middle of the board. Next when client B is asking the server, the server tells client B that there is an "X" in the middle now. Client B renders the "X" and now it is the turn of player B. The following figure shows polling in Tic-Tac-Toe:

During this process, client B keeps sending messages to the server and the server keeps responding to client B just to tell it that nothing happened. This dramatically increases the network loading and server loading. And this is just a two-players example. What if there are eight other players watching this game as spectators? Every player sends a message to the server and get a response message from the server in every second. Imagine there are 100 rooms and 10 players in each room. Now we are talking about 1000 messages per second just for asking the server if there is any update.

Moreover, there is an update latency problem in polling. When player A updates the board, player B knows the update from player A next time when his machine asks the server. This latency depends on the polling interval. A short interval improves the latency problem while putting more load on the server and network. A long interval with large latency makes it unacceptable for real-time interaction between players.

Another disadvantage of polling is the bad scalability. A server needs to keep responding to the polling clients that use relatively lots of system resources. This results in the server only being capable for a few concurrent connections. Usually a polling server supports up to 300 concurrent connections. I had an experience on creating a Flash multiplayer virtual world with .Net web service backend. Due to the limitation of the server, I had to use the polling approach and it would end up supporting less than 200 concurrent players.

The low concurrent players capacity of a server means it needs many servers to handle massive players' connections at the same time and makes it difficult to manage.

Therefore, polling may be suitable for very small-scale networks and it should be avoided in Flash virtual world.

Socket-based connection

In contrast to polling, a socket-based connection establishes persistent connections to the server. The server sends messages to clients only when it needs and vice versa. There are no more redundant messages such as a client asking the server if there is any update because server will push updates to clients without clients initializing the requests. This is also known as asynchronous socket or event-driven socket.

Take the same Tic-Tac-Toe example with the socket-based implementation. The following diagram illustrates the data flow between player A, B, and the server. There are only three messages in the whole process, player A communicates to the server to put an "X" on the board, player B renders the "X", and a successful acknowledgment of the server to player A. If there are eight spectators in the game, only around 11 messages will be sent to the network in this period instead of 18 messages per second. The following diagram shows event-driven Tic-Tac-Toe:

The event-driven socket-based connection eliminates the polling interval latency. The very low server loading enables almost real-time communication between players for which the latency only depends on the client's and server's Internet connections.

It also allows more concurrent players than the polling architecture and is therefore easier to scale. Normally a socket server can handle thousands of concurrent connections.