We designed a TPS (Tiny Publish Subscribe) for the pub/sub infrastructure. It is currently implemented on top of UDP protocal. Because the connectionless feature of UDP maps perfectly to the nature of Pub/Sub.
TPS Message Structure:
Bit 5,6,7,8 in Byte 1 - Message type
Bit 1,2,3,4 in Byte 1 - Retained
Byte 2,3 - Remaining length
(Optional) Byte 4~19 - Topic Name
Byte 19~(4~) - Data
Message Type:
* Publish
* Subscribe
* Unsubscribe
* Connect
* Disconnect
* Ping
* Ping response
Note: Connect and disconnect do not imply the protocal is connection orianted. It is only used to tell the server whose messages it should care.... read more
Definitions:
1. Publish/Subscribe: inter-agent communication takes place through the raising of events performed by agents via a publish operation. Events are multicast to those agents which have previously registered their interest via a subscribe operation.
2. Shared dataspace: agents communicate by producing, consuming, and testing for the presence of objects in a shared, common repository.
In the game application, we currently have two different models corresponding to each of them. The models both server a purpose that they map the requirements of a game as close as possible to the nature of the coordination infrastructures.
Before we discuss these models, we make our assumption: The virtual world of the game requires multiple servers to drive forward. In order to continue a game, each server needs to exchange information very frequently with other servers.... read more
We are currently in stage I. We discussed the possible implementation of a pub/sub server. Two candidates:
1. Message queue based
2. Use shared dataspace (i.e. linda dataspace) to stimulate pub/sub
There is currently no research to build a pub/sub server using shared space. For most the case, people discribes pub/sub and shared spaces as two architecture for coordination infrastructures. They are normally used as opposite terms.... read more
Note for readers: During the planing process, some of the news will be written in diary format.
After meeting with Will, we setuped our stratage and priority:
I. Build a pub/sub server. Test it with raw data.
II. Build a game server and a game client. We have a few choice here: Modify a quake 2, create a mod for hf2 or build our own one. Will prefers the latest one since it is more pratical object at current stage. Overall, we need to keep the msg protocal as simple as possible now. (It hints a simple game model)
III. Mass distribute clients. Test overall performance.
IV. Optimize game server/client. Try to use exsiting MMOG techniques. Finishing up the opject partitioning model if it is not done.
V. Optimize Pub/sub server. Reduce the bottlenect effect.
Timeline:
The project started on 9th, Nov, 2006. The dead line of the project is in June, 2007.
Scope:
We aims to:
1. Build a high performance publish/subscribe server, following MQTT protocal. It will form a back bone of our ditributed architecture.
2. Develop a distributed MMOG game server based on the idea of object patitioning. It should make use of the pub/sub server and have a very short response time for client request.
3. Build a interactive client-side game to demostrate the power of distributed game server. We prefer a FPS or action game which requires very low latency. Anoter option is to make a network modification to a exsiting game (Quake 2 or Half-life 2)... read more
[Publish/Subscribe as an Infrastructure for MMOG
] project is started as a student project of Imperial College London, supervised by Dr William J. Knottenbelt
Paul H J Kelly, a reader in computer science proposed this project as follwoing:
" The goal of this project is to investigate the design of a high-performance messaging infrastructure to support massively-multiplayer games.
To make a really scalable and highly-responsive, immersive game, we need to devolve responsibility for managing the shared environment, so it is not all handled by a single big server. One solution is to partition the game world into parts served by different machines. ... read more