Why cheated caller?

[Serg Karnauhov]

Progresive calls - made as request\response

how you look at something that would make them as dialogue

start call from dialer (dialog_mode:true = confirm from caller for next step is expected. default dialog_mode:false)

[
           48,
           77133,
           {
               "receive_progress": true
               "dialog_mode": true

           },
           "com.myapp.compute_revenue",
           [give me static 2010, 2011, 2012]
       

-invocation-yeled-result(progres: true - like a caller)

then

call (progress:true = it is fact caller readiness to continue dialogue)

[
           48,
           77133,
           {
               "progress": true
                          },
           
           [give me more]
       ]

or cancel 

[Tobias Oberstein]

Hi,

sorry, I have a hard time understanding what you are talking about.

As far as I understand: a "dialog" style communication that spans
multiple roundtrips .. you can do that at the app level easily.
Progressive call results are something different.

Cheers,
/Tobias

> --
> You received this message because you are subscribed to the Google
> Groups "Crossbar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crossbario+...@googlegroups.com
> <mailto:crossbario+...@googlegroups.com>.
> To post to this group, send email to cross...@googlegroups.com
> <mailto:cross...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crossbario/11ad5b0a-9fe1-432d-90b9-88c1d4f3f735%40googlegroups.com
> <https://groups.google.com/d/msgid/crossbario/11ad5b0a-9fe1-432d-90b9-88c1d4f3f735%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[serg.a.k...@gmail.com]

Hi, its my question, now i am write from new accaunt.

I am about RPC

Remote Procedure Call - has two component

REMOTE PROCEDURE call - application layer

REMOTE procedure CALL - communication layer

Router concent of communication layer, be responsible solely for communication, its mean: REMOTE CALL - and nothing else

wamp has at its disposal all the necessary messages in order to separate the transport layer from the application layer, but does not use. instead of trying to infringe on the transport layer, by imposing him the functionality of the application-level

Now we have a wamp rpc system designed for the scheme the request\response(referred to as rpc) and request\ the distributed response (referred as progressive result)

this caller disadvantaged. (callee may send progressive messages but caller can't)

let me remind: wamp idealogy says, the peers a equal

I think that

1 - need to separate the call from the procedure, and it will be only one correct way, 

otherwise will constantly infringe upon the rights of callee or caller (let me remind: you claimed that separate the application layer from the communication level and focus on communication)

2 - to impose equality through the crutch I described above

let me offer a variation on item 1

creat ENDCALL message

difference between the ENDCALL and CANCEL messages

ENDCALL - normal end of call life cycle, error mesage from peer is not expected

CANCEL - emergency end of call life cycle, error mesage from peer is expected

use call shema

[serg.a.k...@gmail.com]

between 1 and 2 mast be OR

Tobias, i am write to ser...@tavendo.de, the list of required modifications, but the answer have not received. as I understand it your company. could you answer the request.

[Tobias Oberstein]

Am 10.02.2016 um 15:06 schrieb serg.a.k...@gmail.com:
> Hi, its my question, now i am write from new accaunt.
> I am about RPC
>
> Remote Procedure Call - has two component
> REMOTE PROCEDURE call - application layer
> REMOTE procedure CALL - communication layer
> Router concent of communication layer, be responsible solely for
> communication, its mean: REMOTE CALL - and nothing else
>
> wamp has at its disposal all the necessary messages in order to separate
> the transport layer from the application layer, but does not use.

WAMP does indeed clearly separate the transport layer from the WAMP
protocol layer:

5.3 Transports

https://tools.ietf.org/html/draft-oberstet-hybi-tavendo-wamp-02#page-17

The value of this has paid off big time: Crossbar.io supports dozens of
transports.

> instead of trying to infringe on the transport layer, by imposing him
> the functionality of the application-level
>
> Now we have a wamp rpc system designed for the scheme the
> request\response(referred to as rpc) and request\ the distributed
> response (referred as progressive result)
> this caller disadvantaged. (callee may send progressive messages but
> caller can't)
> let me remind: wamp idealogy says, the peers a equal

Yes, you are right.

And yep, "progressive calls" is still missing (but we'll have it):

https://github.com/wamp-proto/wamp-proto/issues/167

>
> I think that
> *1 - need to separate the call from the procedure*, and it will be only
> one correct way,
> otherwise will *constantly infringe upon* the rights of callee or caller

> (let me remind: you claimed that separate the application layer from the
> communication level and focus on communication)

Sorry, I don't understand what you mean:(

> 2 - to impose equality through the crutch I described above
>

> /let me offer a variation on item 1/

> creat ENDCALL message
> difference between the ENDCALL and CANCEL messages
> ENDCALL - normal end of call life cycle, error mesage from peer is not
> expected
> CANCEL - emergency end of call life cycle, error mesage from peer is
> expected
> use call shema

There is no need for a new WAMP message. When a caller has issued a
call, and then cancels the call, there are multiple way how the router
can react regarding the callee (eg cancel the invocation, ignore
anything that might come back form the callee later, ..) - but in all
cases, the router must send a ERROR message to the original caller.

Otherwise the caller would have no clue and the outstanding call would
just sit idle within the client.

--

It might be easier for me to understand if you tried to explain your
high level _goals_ (from a use case perspective), rather than jumping
into protocol design proposals. Because then I have to reverse engineer
what you might have had in mind first;)

Cheers,
/Tobias

>
> --
> You received this message because you are subscribed to the Google
> Groups "Crossbar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crossbario+...@googlegroups.com
> <mailto:crossbario+...@googlegroups.com>.
> To post to this group, send email to cross...@googlegroups.com
> <mailto:cross...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/crossbario/cabdb4c5-7d59-44d0-9729-f173c72df8d9%40googlegroups.com
> <https://groups.google.com/d/msgid/crossbario/cabdb4c5-7d59-44d0-9729-f173c72df8d9%40googlegroups.com?utm_medium=email&utm_source=footer>.

[serg.a.k...@gmail.com]

I write using a translator, it sometimes turns ugly. if some text is not understandable - emphasize it, I'll rephrase.

It would be great if wamprpc acted like a phonecall, which connects the two endpoits on peers really

session.call(procedure, endpoint, options)

Arguments:	procedure (URI) – the URI of the procedure to register endpoint (callable) – the function that provides the procedure implementation options (object) – optional - specifies options for registration (see below)

we need to specify two timeout for router: 

for rpc estalishment (timeout between call without arguments and ??result?? message from caller)

for rpc progress (timeout between caller ??result?? and callee result messages)

at the expiration time, the router sends error mesages to both caller and callee

Callee and caller has their timeouts(WAMP CLIENTS)

at the expiration time, the caller or callee send error message to router

how will peers communicate, it is a choice of endpoints

so when calle makes a call, it reports his timeout to the rpc

caller to dealer - call, logincall_timeout:1000  prc_timeout:2000

dialer compares timeouts  - dealer  timeout<caller  timeout - sends dealer logincall_ timeout

dialer to caller and callee- invacation, logincall_timeout:500  prc_timeout:1000

further, according to the principle

caller - yeled - dialer - result - callee

 or

calle - yeled - dialer - result - caller

both caller and callee can close call with cancel 

caller - cancel- dialer - interrupt - calle  and dialer - error - caller 

 or

callee - cancel- dialer - interrupt - caller and dialer - error - callee

I hope I wrote all clear and my idea is clear to you