Ranganath s wrote:
Firstly
i would like to know how Asynchronous Message works from server to client.
Does that message get the response from the received end? if so what would
be the duration of it?
two way messages (we call them actions) to the client work exactly like
two way messages to the server. the message sender formats the message
and puts it on the wire and waits for a response. the message receiver
reads the message from the wire, dispatches it to the appropriate
implementation method, then formats the result (which may be a value
including null, void, or an exception), and puts that on the wire back
to the sender.
one way messages (we call them events) are slightly different. just as
for two way messages, the sender formats the message and puts it on the
wire. but then the sender returns immediately. as above, the receiver
reads the message from the wire and dispatches it. if the implementation
method returns normally (non-exception case), then nothing else is done.
if the implementation method fails, then a special message with the
exception is formatted and returned to the sender. normally this would
fall into the "unwanted" message handler, delivered to the sender via
_sessionNotify method. more or less an "FYI" thing.
the only thing changed by the asynchronous receiver tag in the above two
scenarios is this: when the message is read from the wire, that thread
(the message receiver thread) normally also dispatches the message to
the implementation method. obviously while the implementation method is
running no more messages can be read and dispatched. under asynchronous
delivery, the message receiver thread hands the message to a thread pool
to perform the task of calling the implementation method. the message
receiver thread is then free to read and dispatch more messages. which
means two things: asynchronous receiver messages can be executed out of
order relative to other messages, each other, and in fact might be
executed simultaneously to other messages; second, responses of
asynchronous receiver messages might be delivered out of order relative
to their execution sequence, with other messages and themselves.
basically, when you have an asynchronous receiver declaration in the
idl, you have to take much more responsibility for synchronization
issues with respect to those methods and the rest.
not sure what "if so what would be the duration of it?" means.
secondly , say i have a scenario where in i have 1 server say s1 with
4 clients say c1,c2,c3,c4 now when ever i change some data in c2 that needs
to reflect in other clients as well.. So how could this be handled in Apache
ETCH.
etch itself doesn't handle such a thing automatically. it is a message
passing system, not a data sharing system. but you can use etch to
handle data change scenarios like this:
if one of the clients changes some data, it uses a one way method to
notify the server of the change. let's call that method
dataChanged(...). let's assume the data is identified by name, the value
can be any data type. let's declare dataChanged like this:
@Oneway
@Direction(Both)
void dataChanged(string name, object value)
the server, when it receives a dataChanged, updates it's copy and also
turns around and calls each of the client's with the same information
(the dataChanged method is bi-directional, so either client or server
can call it). the clients, when they receive a dataChanged call, write
down the new value, and life is good.
sort of. if c1 is telling the server that the value changed, obviously
the server need not tell c1 the value changed. that's pretty easy.
the server needs to maintain a list of interested clients. in
particular, when a client connection goes down, it should be removed
from the list.
failure to send to a client should also not stop notification of other
clients.
if both c1 and c2 change the same value, their messages will cross each
other in transit and it is not defined what final value everyone ends up
with. you would need to add a locking protocol and some sort of conflict
resolution mechanism.
scott out
