Re: Software Architecture/Design

Ups...a quick fix. It is of course HTTP requests and not HTML requests
at this level :-)
 
[MakeServerSocket] -> ServerSocket
ServerSocket -> [ReadServerSocket] -> ServerSocket+ClientSocketList
ClientSocketList -> [ClientSocketFilter] -> ClientSocketList
ClientSocketList -> [ReadClients] -> ClientSocketList+HTTPRequestList
HTTPRequestList -> [Router] -> ImageRequestList+ApplicationRequestList
ImageFiles -> [ImageCacheLoader] -> ImageCache
ImageRequestList+ImageCache -> [ImageRequestHandler] -> HTTPReplyList
ApplicationRequestList+ApplicationState -> [ApplicationRequestHandler]
-> ApplicationState+HTTPReplyList
HTTPReplyList -> [WriteClients] -> HTTPReplyList+ClientSocketList
 
Morten

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Morten Brodersen
Sent: Saturday, 5 June 2010 12:23 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Software Architecture/Design


You are welcome Morten (hey! somebody else who is also called
Morten...doesn't happen every day :-) and thanks for your comments. Very
interesting!
 
I some time ago used the approach to write a fast multi-threaded web
server in C#. A bit similar to what you are describing here. The
architecture was roughly as follows (according to memory):
 
[MakeServerSocket] -> ServerSocket
ServerSocket -> [ReadServerSocket] -> ServerSocket+ClientSocketList

ClientSocketList -> [ClientSocketFilter] -> ClientSocketList
ClientSocketList -> [ReadClients] -> ClientSocketList+HTMLRequestList
HTMLRequestList -> [HTMLRouter] ->
ImageRequestList+ApplicationRequestList
ImageFiles -> [ImageCacheLoader] -> ImageCache
ImageRequestList+ImageCache -> [ImageRequestHandler] -> HTMLReplyList
ApplicationRequestList+ApplicationState -> [ApplicationRequestHandler]
-> ApplicationState+HTMLReplyList
HTMLReplyList -> [WriteClients] -> HTMLReplyList+ClientSocketList
 
where the sockets were non-blocking and using a game style tick loop to
execute it. Using the SO/PO approach it was easy to write. And the end
result was an extremely fast mini web server. That was fun to write :-)
 
Morten

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Morten Heiberg
Sent: Saturday, 5 June 2010 12:02 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Software Architecture/Design


This is a really flexible and powerful way of structuring your code and
data.

I have used this approach outside of the games industry in the design
and implementation of a network protocol stack some years ago, and for
that purpose it worked and scaled wonderfully. 

To map things to the terminology of this thread the protocols
(Ethernet/PPP/IP/TCP/UDP/...) were the process objects and the data
packets/network frames were the state objects (along with whatever meta
info they accumulated during processing steps).

This approach made it a breeze to configure new interfaces, set up
protocol tunneling, add support new protocols etc. It was also a great
help during testing and debugging since we could just inject POs at will
or replay previously captured or handcrafted SOs for unit testing. 

Want to test your TCP retransmit code? Just add a simple PO that
randomly drops packets to simulate a noisy connection. Want to test your
IPv4 fragmentation and reassembly code? Inject a PO that buffers and
reorders the packets it receives.

The more polymorph you can keep the PO connection points the more
flexible the system becomes and you can rewire everything to your
liking. Or use them to plug isolated components into a unit testing
framework.

Others have already commented on how much this kind of thinking can help
parallelization efforts. I completely agree. As long as you break down
your POs enough and make sure to encapsulate everything relevant in your
SOs you get multithreading at a reasonable granularity for free.

Another trick (which we used to implement bandwidth management and
quality of service), that I think transfers rather well to game
development, is that you can think of your state objects as your
scheduling units. Your scheduler basically holds all the SOs, sorts them
according to some priority and schedules them to their next PO
accordingly.

This way you can easily set up your AI to run reasoning and perception
code at a lower "framerate" when they are far away from the player (by
making its scheduling priority a function of this distance) and a bunch
of other neat things. You can even use the abstraction to abandon some
non-essential SOs to recover from a framerate drop without having to
write a lot of cleanup code.

Good stuff. Thanks for sharing!

- Morten

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com