Michael Bayne
a285695ca8
condition between the omgr thread and the conmgr thread. Now when the omgr thread processes an event that is going out to the clients, it flattents the message itself for each client that is to receive the message and the flattened data is posted to the conmgr outgoing queue. This means that once an event is finished processing, no further modifications to any of the data associated with the event can effect the data queued up to be sent to the client. This is a good thing, it will eliminate or illuminate a very baffling class of bugs that we've sort of been ignoring because we knew this could be the cause. We used to take an event and flatten it directly into the direct buffer from which we would do our socket write. Now we flatten it into a temporary byte array. This means a metric shitload more garbage generation and collection. We used to do the flattening on the conmgr thread, now we do it on the omgr thread. This means a big redistribution of CPU demand. Either of those things could result in a significant negative impact on our performance, but we'll just have to deploy this stuff and find out. Whee! If it turns out to be a serious problem, there are potential optimizations that could be done by keeping a pool of direct buffers around and flattening messages into them, relying on the fact that the outgoing conmgr queue generally doesn't grow too large and we could allocate tens to a hundred megabytes of memory for the outgoing queue if we really needed to. I'd also like to test the overflow handling stuff more. It didn't really change in that everything just deals with arrays of bytes now instead of unflattened messages, but I'll be more comfortable once I've seen all this in action on ice where there may be few users, but they are just as likely to experience lag and receive an overflow queue as users on the higher traffic servers. There is code to log when overflow queues are created and finally flushed and how much use they got while they were around, so that should give us an indication of whether things are operating properly. git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3419 542714f4-19e9-0310-aa3c-eee0fc999fb1
The Narya library
-----------------
The Narya library provides various facilities for making networked
multiplayer games. It's various packages include:
* geom, util, io - basic tools for doing networked I/O, data structure
manipulation and some geometry math
* resource - tools for bundling, deploying and managing media (images,
sounds, etc.) with a game
* media - a framework for doing "active" rendering in Java
* media.image - tools for loading, caching, manipulating and displaying images
* media.sound - tools for loading, caching, and playing audio
* media.animation, media.sprite - works in concert with the active
rendering system and provides tools for defining and manipulating
sprites (graphical entities that follow paths) and animations
(graphical entities that affect the display in other ways)
* miso - a framework for defining and displaying isometrically rendered scenes
* presents - a framework for distributing information among a server and
networked clients
* crowd - builds on the presents framework to create the notion of
bodies and rooms and provides chat infrastructure
* whirled - builds on the crowd framework and defines a scene graph with
portals to move between scenes and provides hooks for distributing and
updating scene data (for example isometric rendering information) over
the network
* cast - a framework for defining and using recolorable, composited
characters with different poses and actions
* parlor - builds upon the crowd framework to create the notion of a
game with players and provides tools for making turn based games
* puzzle - builds on the parlor and media frameworks to provide tools
for implementing puzzle games in a networked environment
* micasa - builds on the parlor framework to provide lobbies and
matchmaking for multiplayer games
Documentation is somewhat sparse at the moment, but inspection of the code
in the tests/ directory shows examples of use of many features of the
library.
Building
--------
Building the library is very simple. First ensure that the necessary third
party jar files are available either in the lib/ directory or in the
system wide jar file location specified in build.xml. See lib/README for a
list of the necessary third party jar files and how to get them.
The library is built using ant, a modern build tool available from The
Jakarta Project. If you aren't already using ant for other projects, it
can be found here:
http://jakarta.apache.org/ant/
Invoke ant with any of the following targets:
all: builds the distribution files and javadoc documentation
compile: builds only the class files (dist/classes)
javadoc: builds only the javadoc documentation (dist/docs)
dist: builds the distribution jar files (dist/*.jar)
Distribution
------------
The Narya library is released under the LGPL. The most recent version of
the library is available here:
http://www.threerings.net/code/narya/
Contribution
------------
Contributions to Narya are welcome. Control of the CVS repository is
presently in the hands of mdb@threerings.net, who should be emailed about
submissions. Soon we will be migrating to Subversion and making the
repository publicly accessible. For now, source releases are available at
the above website.
Contact Information
-------------------
Narya is actively developed by the scurvy dogs at Three Rings Design,
Inc. Contact Michael Bayne <mdb@threerings.net> with questions, comments
and other wordly endeavors.
$Id: README,v 1.1 2004/08/27 17:44:44 mdb Exp $