Design patterns for servers with long life sockets?

On Sun, 24 Aug 2008 15:17:44 -0700 (PDT), magnus.wolffelt@gmail.com wrote:

>> Try:http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf
>
> Very cool from first look. Will definitely read the whole paper. This
> is what I was looking for.

(Huh, earlier you have responded that active objects were too complex for
you... (:-))

But the pattern indeed is quite common in the middleware, as the authors
state. We have deployed something alike on multiple occasions. It is of
course a bit simplified as described in the paper. Nevertheless it is a
good start.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"magnus.wolffelt@gmail.com" <magnus.wolffelt@gmail.com> writes:
>> Warning: It will lead you to ACE, which will appear to satisfy your
>> requirements... at the cost of your mortal soul. Other than that -
>> no strings attached!
>
> No worries - I intend to keep this in Java.

My condolences.

> . perhaps using some existing tools like:
> http://java.sun.com/j2se/1.5.0/docs/...utureTask.html
> and
> http://java.sun.com/j2se/1.5.0/docs/...kingQueue.html
> and
> http://java.sun.com/j2se/1.5.0/docs/.../Executor.html

You left out http://www.jini.org. Look at the Master-Worker
pattern, mediated by a JavaSpace, among others.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Responding to Magnus.wolffelt...

Perryman and Daniel T. suggested variations on a basic theme: separate
the concerns. IOW, render unto TCP the things that are communication and
render unto the Game things that are gamey.

The game needs to communicate with various players. TCP provides a
mechanism to do that. But the game doesn't care if you talk to the
player via TCP or smoke signals; it just needs to pass information to
and receive information from the player independently of particular
communication paradigms. If you provide a "firewall" interface to
separate those views you will find it is much easier to resolve them
individually.

The best way to do that is to identify subject matters that are distinct
by needing different paradigms, rules, and levels of abstraction. Then
encapsulate each subject matter as a subsystem or layer behind a generic
interface that captures the invariants of the subject matter from the
client's perspective. Then you can resolve each subject matter as
essentially a standalone problem of mapping the client's needs into the
way the subject matter views the world, which should simplify things a
great deal because you can abstract each subject matter domain in a
highly tailored fashion without being distracted by details in other
subject matters. (The "Application Partitioning" category on my blog
talks about this in more detail.)

I suspect you will find it convenient to think of <at least> three
distinct kinds of functionality: (1) game activities (e.g., login, ogre
attacks, game threads, etc.); (2) high level control of network
communications (e.g., opening sockets, queuing messages, etc.); (3) low
level message network grunt work (e.g., message formatting, ack
handshaking, etc.). In particular, note that (3) needs to know nothing
about game semantics; it just manipulates messages and talks to a port.
Similarly the view of game semantics in (2) is also very limited; it
effectively encodes/decodes interface messages into subsystem
abstractions and re-dispatches to methods based on an interface message
identifier.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On Aug 25, 5:55 pm, "H. S. Lahman" <h...@pathfindermda.com> wrote:
> Responding to Magnus.wolffelt...
>
> Perryman and Daniel T. suggested variations on a basic theme: separate
> the concerns. IOW, render unto TCP the things that are communication and
> render unto the Game things that are gamey.
>
> The game needs to communicate with various players. TCP provides a
> mechanism to do that. But the game doesn't care if you talk to the
> player via TCP or smoke signals; it just needs to pass information to
> and receive information from the player independently of particular
> communication paradigms. If you provide a "firewall" interface to
> separate those views you will find it is much easier to resolve them
> individually.
>
> The best way to do that is to identify subject matters that are distinct
> by needing different paradigms, rules, and levels of abstraction. Then
> encapsulate each subject matter as a subsystem or layer behind a generic
> interface that captures the invariants of the subject matter from the
> client's perspective. Then you can resolve each subject matter as
> essentially a standalone problem of mapping the client's needs into the
> way the subject matter views the world, which should simplify things a
> great deal because you can abstract each subject matter domain in a
> highly tailored fashion without being distracted by details in other
> subject matters. (The "Application Partitioning" category on my blog
> talks about this in more detail.)
>
> I suspect you will find it convenient to think of <at least> three
> distinct kinds of functionality: (1) game activities (e.g., login, ogre
> attacks, game threads, etc.); (2) high level control of network
> communications (e.g., opening sockets, queuing messages, etc.); (3) low
> level message network grunt work (e.g., message formatting, ack
> handshaking, etc.). In particular, note that (3) needs to know nothing
> about game semantics; it just manipulates messages and talks to a port.
> Similarly the view of game semantics in (2) is also very limited; it
> effectively encodes/decodes interface messages into subsystem
> abstractions and re-dispatches to methods based on an interface message
> identifier.
>
> --
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> h...@pathfindermda.com
> Pathfinder Solutionshttp://www.pathfindermda.com
> blog:http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> i...@pathfindermda.com for your copy.
> Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH

Yep yep, I was doing something a little like that already, just very
unstructured. Currently working on applying the active object pattern
to my code.

Thanks.