Re: Questions about the Event Dispatch and asynchronous callback

[scott comer <we...@mac.com>]

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

Re: Questions about the Event Dispatch and asynchronous callback

[Ranganath s <ra...@gmail.com>]

thanks a ton for the explanation.

regards
Ranganath


On Tue, Jan 12, 2010 at 8:33 PM, scott comer <we...@mac.com> wrote:

> 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
>
>
>
>


-- 
I blog at http://ranganaths.wordpress.com