Why cheated caller?

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



0 Likes

#2

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

···

Am 09.02.2016 um 03:41 schrieb 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

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

0 Likes

#3

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

0 Likes

#4

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.

0 Likes

#5

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.

···

Am 10.02.2016 um 15:06 schrieb serg.a.k...@gmail.com:

--

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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#6

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

0 Likes