Re: which way I should go?
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sun, 11 Dec 2005 16:20:31 GMT
Responding to Yaoyang...
So far I write and meet some servers that always msg -based. I encode /decode Msg to byte stream. I write basic TcpProtocol Process class.
OK.
I can't catch what your meaning about the description of synchronization.
If you use a pure data transfer interface, then you can't pass objects. But the client and the server may have to abstract the same problem space entity. That means the client and the server both have an object with the same identity that is separately instantiated. Since the client and server have quite different responsibilities, those two objects will be abstracted with different suites of behaviors since the client and server deal with different functional requirements.
But they may share some of the same knowledge (i.e., have the same knowledge attributes). That's because different behaviors can operate on the same data. When two objects in different subsystems have the same data values it is critical that those data values be the same because they abstract properties of the same underlying entity. So if one subsystem changes one of the values, the corresponding value in the other subsystem must also change. Maintaining that data consistency requires synchronization of data changes across the interface between client and server.
IOW, if pure message interfaces are employed, one price one must pay is ensuring data integrity across the subsystems.
when I say Asynchronization I mean that when I launch a request msg (for example GetPlayerDetail ) I push the msg to the object server and not wait the response .
That's fine...
the server keep running (for example keep processing client request). My question is when the response return how can I resume the GetPlayerDetailed routine? Is there any common simple graceful sollution.
Whenever asynchronous processing is involved the most commonly used paradigm is state machines. The state machine transitions enforce constraints on the sequencing of operations. When two state machines interact (e.g., one in the client and one in the server), those constraints effectively form a communication protocol. (In fact, it is quite common in the telecom arena for requirements to be described with state machines.)
[As it happens, the mathematical rules for finite state automata happen to match up very nicely with basic OO notions. For example, a state cannot know what the last or next states are. That dovetails with the OO notions of intrinsic responsibilities that are logically indivisible at the class' level of abstraction, implementation hiding, and cohesion. Similarly, event-based communications are an ideal form of pure peer-to-peer collaboration between objects.]
Now I resume the GetPlayerDetail context through the MsgID. When I meet the MsgID representing the GetPlayerDetail and Msg Type is response I know I must go to the GetPlayerDetail routine...
what your mean when you mention event-based and synchronization.
I don't know your game so the following is just an example of a plausible protocol in, at best, somewhat familiar terms. Suppose on the client side you have a Player object with the following state machine:
[Initialized]
|
| E1:start
|
V
[Game Requested]
|
| E2:game available(n)
|
V
[Logged Into Game]
|
| E3:ready
|
V
[Ready To Act] <------------------+
| |
| E4:action selected(a) | E3:ready
| |
V |
[Move Requested] -----------------+State conditions and actions:
Initialized: is the startup state for a [Player] when the game starts
Game Requested: the state action sends the E6:new player(p) message to the server.
Logged Into Game: creates a [Game] object on the client side with the game number, n, as an attribute. The associated action sends the E7:log player in(p) message to the server.
Ready To Act: basically a wait state that waits for the client UI to provide an action. It will send a E8:ready for action message to the client UI to request the user to do something. This sort of wait is common in protocols that require handshaking.
Move Requested: sends E9:move selected(n,m) to the server. (Note the game number is encoded in the message data packet.)
Event definitions:
E1:start is probably generated from main() to start playing.
E2:game available(n) is the response from the server that a game is available.
E3:ready is the response from the server has completed some requested action and is ready to accept other actions. Note that the same <generic> acknowledgment event is used in two contexts.
E4:action selected is the response from the UI with the user's choice of game action.
Of course this is an oversimplification because it doesn't deal with all scenarios (e.g., no game is available) and processing actions is probably more complicated (i.e., involving different objects). However, it does demonstrate the enforcement of a rigid sequence of interactions between player, UI, and server. If you walk through the sequencing you will see that nothing new happens until a necessary response is received. [Alas, it is harder to follow in this form than in, say, UML, because text is so limited.]
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- which way I should go?
- From: yaoyang
- Re: which way I should go?
- From: H. S. Lahman
- Re: which way I should go?
- From: yaoyang
- which way I should go?
- Prev by Date: Re: which way I should go?
- Next by Date: Re: Library Circluation
- Previous by thread: Re: which way I should go?
- Next by thread: Re: which way I should go?
- Index(es):
Relevant Pages
|
