Old Wiki:EVEmu Architecture
Contents |
EVE Emulator Software Architecture
The software architecture is mostly based on the current understanding of the real EVE architecture, except it is a single node.
this needs a lot more expansion, im just quickly capturing key concepts right now..
Layers
the network code for EVEmu is organized into four basic layers right now:
1.Application Layer - This is where the application logic resides... right now the only application logic which we have is that which is required to excercise the protocol. there is no intent at this point in development to expand the application layer to a playable point (until the network protocols are better understood).
2.Service Layer - The service layer is really responsible for taking packets from the network and dispatching them to the correct service object (and possible bound sub-object), so that it can service the request.
3.Presentation Layer - The presentation layer is reposible for interpreting or generating the raw bytes transported by the network into concepts that the service and application layer can understand. Because the live EVE is based on python, the packets sent over the wire are a serialization of python objects (similar to pickling). The sort of python primitives which the presentation layer deals in are things like lists, tuples, dicts, ints, strings, etc... This layer also takes care of compression using zlib.
4.Network Layer - The network layer of EVE is realatively simple, and is responsible for getting packets of serialized data across the network in one piece.. they use TCP, so this layer only has to deal with dividing the link up by packet length. Code Organization
The code in the server is very service-centric right now... packet come in and get dispatched to the correct service for the request. The service then takes appropriate action on the packet and returns the result. There is a Client object which represents the current state of the client, but for the most part, as much as possible of the logic should be implemented in the service objects.
Bound Objects
One important concept to learn about is "bound objects"... this is essentially a way for the client to request an "instance" of a service which retains some context about what it is... think of it as creating a new remote object on the server, on which the client can make direct calls, instead of calling into the service itself each time. The bound object's "constructor" takes some arguments that tell it, for example, what ship it represents. From then on, its implied by making a call on the bound object that the client is talking about that specific ship, etc... Calls on bound objects are also more optimal on the network, because they specify exactly where they are going (node and a routing number), instead of specifying the service name and other routing parameters...
Packet Generation
Because EVEmu is being written in native C++, and the data on the wire is more python-friendly, I developed an XML based system for laying out the contents of a message in a more C++ friendly structure. The various files in packets/*.xml represent service and application layer messages