HTML and CSS Reference
In-Depth Information
The Basic Architecture of a Socket-Server Application
Now that you have ElectroServer ready to go and you have the JavaScript API, it is time
to learn a bit about how socket-server-based multiplayer/multiuser applications are designed.
Using a socket server means you are creating an application that relies on a client for input
from a user, as well as relying on a server to distribute that input to other users who are con-
nected to the first user.
A good example of this is a chat application. Most chat applications require a user to enter a
room
(a logical space in which people are “chatting”—that is, exchanging messages), where
that user can see the messages of other people in the same virtual space. In that room, the
client is “connected” to those other users. However, it is usually not a direct connection (such
as peer-to-peer), but instead, it is a connection through a port to a socket server.
The socket server acts as the traffic cop for the chat messages. It listens on a port (in our case,
8989)formessagescominginfromtheclients.Thosemessagesneedtobeformattedinaway
that the server can understand so that it can process them. The JavaScript API we will use
performs this formatting for our client applications.
When the socket server receives a message from the client, it routes the various text messages
sent by each client back out to the other clients in the room. However, it can also do much
more by using server-side processing, such as holding the list of current messages, so that
peopleenteringtheroomwhilethechatisongoingcanseewhathasbeensaidpreviously,scan
chat messages for swear words, award points to users for their input, or anything else you can
dream up.
Whentheserverfinallyprocessesthemessageandsendsitback,theclientthenprocessesthat
message. In the case of the chat, that processing usually involves displaying the message on
the canvas.
