The settings are there for doxygen to make the docs and eventually I
will unignore the docs (html) dir when I figure out how to have it not
trying to document things like the RSA and sqlite (HUUUUGE!) embedded
libs.
this begins the work on the actual user account logon procedure. three
cases: 1. create unused account when client does not currently own an
account, 2. log in to client's own account, 3. log in to account not
owned by client but linked from another account (whitelisted for log in
by this client) using a password
That ugly "TODO message" challenge has been replaced with 192-bit (32
printable characters) challenge strings generated with boosts's ND
randomness source to avoid seed-guessing and similar exploits attacking
pseudorandom generation.
similar to boost::asio async methods (that post to a callback) the
call_method method of sessions now uses a similar callback mechanism to
report methodcall completions.
in this case atomic means the receiver of a method call or death message
expects the operands before further processing (such as placing things
onto argument stack). prior the primitive types were using the argument
stack with objectrefs but this behavior is not well defined if the
stream lags before the method call or death message opcodes arrive and
the receiver potentially processes input as a naked objectref (not
knowing the future to expect an incoming . or ~) resulting in a data
race within the protocol (if one end is expecting a value on the
argument stack at same time other end sends a death message or object
part of method call the data race has begun)
when polling during the renderloop async_reads were stacking (one per
frame!) up to wait for the same input byte. about 10-12 seconds of
this mega-leak was enough for the system to complain with an eventual
10055 (buffers full). a flag is used per session (thread-local) to
ensure this no longer happens. a new reader job is no longer posted
until the previous reader job completed. the session's run method
should not have this problem but just to be safe it used the flag also.
along the way I also made all the names of io_service's unique as part
of the check to make sure each thread (including server connection
slaves) has a unique io_service object (otherwise jobs are shared across
threads and that would be crossing the streams and bad and all that
stuff)
cleaned up shutdown handling for clean thread shutdown (not the ugly
force-termination I had before). also finally found a solution to make
irrlicht's logging messages use the locking macros
Brian Jack